De overdracht van gedachten van Theodore Ts'o, de maker van het Ext4-bestandssysteem, over de ontwikkeling van ext4, het BcacheFS-bestandssysteem, de Linux-kernel, ZFS, het gedragscode en bestandssystemen in het algemeen: <\/p>\n
Over de ontwikkeling van ext4<\/b>. <\/p>\n Bij elke released van de ext4-kernel dragen meer dan een dozijn mensen bij. Momenteel besteed ik het grootste deel van mijn tijd aan het beoordelen van code, het uitvoeren van tests en het verbeteren van de testtoepassing {kvm<\/a>,gce,qemu,android}-xfstests. En ik vertrouw sterk op 2-3 andere ontwikkelaars die bij SUSE en IBM werken en die me helpen met het beoordelen van code. <\/p><\/blockquote>\n Over BcacheFS<\/b> <\/p>\n Eerlijk gezegd is bcachefs niet een volledig op zichzelf staand project - bijvoorbeeld, Kent was de auteur van 72% van de patches tussen de versies van de kernel 6.11 en 6.12, terwijl ik het auteur was van precies 0% van de 103 patches voor ext4 in dezelfde periode. Dit komt omdat ik er stevig van overtuigd ben dat programmeren een teamsport is, en mijn rol als technisch leider is om de deelnemers aan ext4 in staat te stellen alles te doen wat mogelijk is om het bestandssysteem te verbeteren. We houden wekelijkse conferenties, en Derrick Wong, de senior ontwikkelaar van XFS en voormalig maintainer van XFS, neemt deel aan deze conferenties - en ik heb hem geholpen met XFS-testvragen, terwijl Derrick mij heeft geholpen met verschillende ext4-testvragen en zelfs een paar ext4-patches heeft bekeken. We werken samen, en dat is goed. <\/p>\n Ik laat anderen beslissen of ze hun gegevens willen toevertrouwen aan iemand die een eenzame, getalenteerde programmeur is, die misschien wel getalenteerder is dan ik, maar ik geef je een hint - je kunt 'bedriegen' door een team bij het oplossen van problemen te betrekken. Het is niet nodig om dit alleen te doen. Natuurlijk, daarvoor moet je weten hoe je het beste in anderen kunt naar boven halen, en je moet samenwerken. En een beleefde benadering van elkaar in mailinglijsten kan geen kwaad. <\/p><\/blockquote>\n Over de kernel, CoC, mogelijkheden en de toekomst van ext4<\/b> <\/p>\n Ext4 krijgt inderdaad enkele nieuwe functies, maar dit zijn de functies die bedrijven bereid zijn te financieren, omdat de ontwikkeling van de functie zinvol is vanuit kosten- en batenperspectief. Zo waren bijvoorbeeld fscrypt en case-insensitive directories functies die nuttig waren voor Android en Chrome OS, en deze werden ten minste gedeeltelijk gefinancierd door deze ontwikkelteams (Steam maak ook zorgen over case-insensitivity en steunde een van de ingenieurs). We willen ondersteuning voor 'untorn' writes toevoegen, omdat dit de prestaties van databases op cloud-ge\u00ebmuleerde blokapparaten zal verbeteren, waar 16k atomische schrijfacties kunnen worden gegarandeerd, wat dubbele buffering in MySQL en PostgreSQL elimineert. <\/p>\n (In feite kunnen Amazon en Google dit doen in hun eigen databasesystemen, door aannames te maken over hoe Amazon EBS en Google Persistent Disk werken, maar we willen dit op een algemenere manier doen die op de lange termijn beter ondersteunbaar is). Het is minder aantrekkelijk dan dingen zoals reflinks, maar de return on investment is veel gemakkelijker te rechtvaardigen, zowel omdat de kosten lager zijn (minder werk voor ontwikkeling, testen en kwalificatie voor enterprise-implementatie) als omdat de voordelen veel gemakkelijker kwantitatief te beoordelen zijn. Dingen zoals 'ik kan de salarisvergoeding van XX vaste programmeurs besparen over een periode van vijf jaar' zijn veel gemakkelijker te doen voor dit soort prestatieverbetering functies. <\/p>\n In tegenstelling tot dit zijn reflinks — leuk, maar ik kon geen klant vinden die bereid was de ontwikkelingskosten te betalen, of een bedrijf dat dacht dat hun klanten meer van hun product zouden kopen als ze reflinks aan ext4 zouden toevoegen. Dit klinkt misschien vreselijk corporatief, maar er is een verhaal over hoe ZFS-ingenieurs een project vanuit het niets zijn begonnen, zonder toestemming van het management en zonder voorstellen van de verkoopafdeling, en Sun iets presenteerden dat feitelijk al was gebeurd. <\/p>\n Het klinkt geweldig, maar als je je herinnert dat Sun uiteindelijk geld begon te verliezen totdat het gedwongen werd zichzelf aan een ander bedrijf te verkopen, en dat de ingenieursorganisatie die ZFS ondersteunt, niet langer bestaat. Ongeveer rond de tijd dat ZFS werd aangekondigd, was ik betrokken bij een bedrijfsonderzoek om te zien of het de moeite waard was te investeren in besturingssysteemfuncties voor AIX en Linux — en we kwamen tot de conclusie dat het niet het geval was, de ROI was laag en de nieuwe besturingssysteemfuncties zouden niet leiden tot meer klanten die hardware, software of IBM-systemen kochten. Misschien ging het slecht voor IBM, maar het bestaat nog steeds, en Sun — dat doet het niet. <\/p>\n Ongeveer in diezelfde tijd kwamen vertegenwoordigers van verschillende Linux-bedrijven samen om na te denken over hoe Linux zou kunnen concurreren met ZFS. Tijdens deze bijeenkomst werd het idee geopperd dat btrfs de langetermijnoplossing zou zijn, terwijl ext4 een kortetermijnoplossing zou zijn die ondersteuning zou bieden voor zaken zoals realtime resizing, 64-bits bloknummers en andere dingen die in traditionele Legacy Unix OS aanwezig waren en die niet in ext3 voorkwamen. <\/p>\n Tijdens die bijeenkomst werd ik gevraagd te bepalen wat er nodig zou zijn om een geheel nieuw bestandssysteem te cre\u00ebren. Ik heb onderzoek gedaan naar hoeveel inspanning vereist was voor het maken van bestandssystemen zoals GPFS en JFS van IBM, advfs van Digital, en heb ingeschat hoeveel Sun heeft besteed aan de ontwikkeling van ZFS en het volledig productieklare maken van dit bestandssysteem. Het antwoord dat ik kreeg, was ongeveer 100 persoon-jaar, met een lage schatting van 50 persoon-jaar en een hoge schatting van 200 persoon-jaar (maar dat was voor GPFS, dat een clusterbestandssysteem was en dus veel moeilijker). <\/p>\n Ik meldde dit tijdens een vergadering, en een senior engineer van Intel zei: «Nee, vertel dit niet aan de leiding, want ze zullen het project nooit goedkeuren! Zeg tegen hen dat btrfs over 18 maanden klaar zal zijn». Ik laat mensen zelf bepalen wanneer btrfs de status van «gereed voor professioneel gebruik» bereikt, vooral voor die nieuwe aantrekkelijke geavanceerde functies die moesten concurreren met ZFS, maar ik denk niet dat het ter discussie staat dat dit niet gebeurde binnen 18 maanden. <\/p>\n En zelfs voordat Sun uiteen viel, weigerden veel bedrijven die hun vertegenwoordigers naar de vergadering stuurden de deelname van ingenieurs aan het btrfs-project, en dat hielp natuurlijk niet. Maar waarschijnlijk had dit te maken met het feit dat bedrijven \u2014 rationele organisaties zijn die eigen beslissingen nemen over de rentabiliteit van investeringen, en financiering van een nieuw bestandssysteem niet dezelfde zin had als mensen vertellen dat Linux een antwoord op ZFS zou hebben. <\/p>\n Terugkijkend kunnen we zeggen dat, hoewel ZFS echt geweldige functies had, ze niet voldoende waren om de meeste gebruikers te overtuigen Solaris te kiezen boven de veel goedkopere x86-platforms met Linux. En tegen de tijd dat Sun besloot om de OpenSolaris-strategie en Solaris x86 te proberen, was het al te laat. Het netwerk effect was enorm, en de x86-strategie bood geen antwoord op de vraag hoe \u00e9\u00e9n bedrijf, Sun, alle supergetalenteerde ingenieurs die aan Solaris werkten, kon betalen. Het kopen van een x86-server voor $5000 levert niet veel winst op in vergelijking met server<\/a> SunFire E10k Sparc voor 100000 dollar, die Sun als de 'piek' in de 'dot Com' noemde. <\/p>\n De essentie is dat engineering in de echte wereld een compromis is, en de zakelijke realiteit maakt deel uit van dat compromis. Ik verontschuldig me niet voor het feit dat ik de voorkeur geef aan het eten van voedsel, en dat ik genoeg geld wil verdienen om ooit met pensioen te gaan. En dat betekent op zijn beurt dat ik goed moet begrijpen hoe ik de werkgever ten minste tien keer meer waarde bied dan mijn salaris. Als ik dat kan doen terwijl ik open-source blijf werken en andere bedrijven help geld te verdienen zodat ze bereid zijn bij te dragen aan ext4, nou, dat is een deel van de uitdaging en waarom ik houd van werken met open-source. <\/p>\n En terugkomend op de Gedragscode wil ik zeggen dat bijna alle beheerders van de belangrijkste bestandssystemen de Code ondersteunden, niet vanwege wat vage liberale overwegingen. Dit is omdat we elke ingenieur nodig hebben die bereid is bij te dragen aan ons project, en de meesten van ons hebben mensen gezien die weigerden te werken met Linux en overgingen naar andere besturingssystemen (ik ken iemand die naar Windows is overgestapt en een waardevolle Linux-kernelontwikkelaar was bij IBM Linux Technology Center) of werkten aan interne projecten, maar niet aan wat samenwerking met de LKML vereiste, vanwege de giftige omgeving van enkele mensen op de mailinglijst. <\/p>\n In sommige gevallen waren de zorgen ongegrond; bijvoorbeeld, Linus schreeuwde tegen een senior ontwikkelaar die het beter had moeten weten en met wie Linus in de meeste gevallen persoonlijk omging, en zij hadden al een gevestigde relatie. Het probleem is dat nieuwkomers dit niet wisten en bang werden \u2014 'wat als Linus me publiekelijk vernederd zoals hij met Steve deed', niet begrijpend dat dit in de praktijk niet zou gebeuren. Dat is waarom we een CoC hebben; het is niet voor ons, senior ingenieurs, maar ter ondersteuning van jongere ingenieurs in onze teams die we willen opleiden om op een gegeven moment ons te vervangen als de tijd komt om met pensioen te gaan, of als we door een bus worden overreden, of als we op een andere manier deze vergankelijke wereld verlaten. <\/p>\n Vergeet niet dat er 50-100 man-jaar nodig is om een bestandssysteem te cre\u00ebren dat klaar is voor gebruik in een bedrijfsomgeving. We hebben alle ingenieurs nodig die we kunnen aantrekken, en velen van ons doen extra werk in hun vrije tijd omdat we om de zaak geven. Het cre\u00ebren van een hoogwaardig bestandssysteem is teamwork, en we hebben elke getalenteerde ingenieur nodig die we kunnen krijgen. Zelfs als \u00e9\u00e9n ingenieur een super programmeur van 10 keer is, als hij uiteindelijk een heleboel andere ingenieurs afschrikt die kunnen helpen met testen, prestatieoptimalisatie, enzovoort, dan is het gewoon niet waard om iemand een idioot te laten zijn. <\/p><\/blockquote>\n\n
\n
\n