Een vertaling van de gedachten van Theodore Ts’o, de maker van het Ext4-bestandssysteem, over de ontwikkeling van ext4, het BcacheFS-bestandssysteem, de Linux-kernel, ZFS, de gedragscode en bestandssystemen in het algemeen:
Over de ontwikkeling van ext4.
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,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.
Over BcacheFS
Eerlijk gezegd is bcachefs geen volledig alleenstaand project — bijvoorbeeld, Kent was de auteur van 72% van de patches tussen de releases van kernel 6.11 en 6.12, terwijl ik voor diezelfde periode precies 0% van de 103 patches voor ext4 heb geschreven. Dit komt omdat ik vast hou aan de mening 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, een senior ontwikkelaar van XFS en voormalig onderhoudsverantwoordelijke van XFS, neemt deel aan deze conferenties — en ik heb hem, zoals bekend, geholpen bij het testen van XFS, terwijl Derrick mij geholpen heeft met verschillende kwesties met betrekking tot het testen van ext4 en zelfs een paar patches voor ext4 heeft bekeken. We werken samen en dat is goed.
Ik laat het aan andere mensen over om te beslissen of ze hun gegevens willen toevertrouwen aan iemand die een alleenstaande programmeur is en die misschien meer talent heeft dan ik, maar ik geef je een hint — je kunt 'gemakkelijker' maken door een team bij het oplossen van een probleem te betrekken. Het is niet nodig om dit alleen te doen. Natuurlijk moet je weten hoe je het beste uit anderen kunt halen en moet je samen werken. En een beleefde omgang met elkaar op mailinglijsten kan geen kwaad.
Over de kernel, CoC, mogelijkheden en de toekomst van ext4
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ëmuleerde blokapparaten zal verbeteren, waar 16k atomische schrijfacties kunnen worden gegarandeerd, wat dubbele buffering in MySQL en PostgreSQL elimineert.
(In feite kunnen Amazon en Google dit doen in hun eigen DBMS-producten door aannames te maken over hoe Amazon EBS en Google Persistent Disk werken, maar we willen dit op een meer algemene manier doen die op lange termijn beter te ondersteunen is). Dit 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 kunnen worden beoordeeld. Dingen zoals 'ik kan de kosten van het salaris van XX fulltime ontwikkelaars sparen over vijf jaar', zijn veel gemakkelijker te realiseren voor dit soort prestatieverbeterende functies.
In tegenstelling tot dit zijn reflinks leuk, maar ik kon geen klant vinden die bereid was de ontwikkelingskosten te betalen, of een bedrijf dat denkt dat hun klanten meer van hun product zullen kopen als ze reflinks aan ext4 toevoegen. Dit lijkt misschien vreselijk corporatief, maar er is een verhaal over hoe ZFS-ingenieurs een project vanaf nul zijn begonnen zonder toestemming van het management en zonder input van de verkoopafdeling, en Sun presenteerden wat feitelijk een fait accompli was.
Dat klinkt goed, maar als je bedenkt dat Sun uiteindelijk verlies begon te maken en gedwongen werd zichzelf aan een ander bedrijf te verkopen, en dat de engineeringorganisatie die ZFS ondersteunt, feitelijk niet langer bestaat. Ongeveer op het moment dat ZFS werd aangekondigd, was ik betrokken bij een onderzoek binnen het hele bedrijf over de vraag of het zinvol was te investeren in bestandssysteemfuncties voor AIX en Linux - en we kwamen tot de conclusie dat dat niet het geval was, de return on investment was minimaal en nieuwe bestandssysteemfuncties zouden niet leiden tot een toename van het aantal klanten dat hardware, software of IBM-systemen aankoopt. Misschien waren het moeilijke tijden voor IBM, maar zij bestaan nog steeds, en Sun niet.
Ongeveer rond dezelfde 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 bieden die ondersteuning zou geven voor zaken zoals realtime schaalvergroting, 64-bits bloknummers en andere zaken die in de traditionele Legacy Unix OS aanwezig waren, maar niet in ext3.
Tijdens die bijeenkomst werd ik gevraagd te bepalen wat er nodig zou zijn om een geheel nieuw bestandssysteem te creëren. 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).
Ik heb dit gerapporteerd tijdens de vergadering, en een bepaalde senior engineer van Intel zei: "Nee, vertel dit niet aan de leidinggevenden, want zij zullen het project nooit goedkeuren! Vertel hen dat btrfs over 18 maanden klaar zal zijn." Ik laat het aan de mensen over wanneer btrfs de status ‘klaar voor ondernemingsgebruik’ bereikt, vooral voor die nieuwe aantrekkelijke uitgebreide functies die zouden moeten concurreren met ZFS, maar ik denk niet dat het ter discussie staat dat dit niet binnen 18 maanden is gebeurd.
En zelfs voordat Sun uit elkaar viel, weigerden veel bedrijven, die hun vertegenwoordigers naar de bijeenkomst stuurden, deel te nemen aan het werk aan btrfs, en dat hielp natuurlijk niet. Maar waarschijnlijk had dit te maken met het feit dat bedrijven rationele organisaties zijn die zelf beslissingen nemen over de terugverdientijd van investeringen, en het financieren van een nieuw bestandssysteem had niet dezelfde waarde als vertellen dat Linux een antwoord op ZFS zou hebben.
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 één 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 SunFire E10k Sparc voor $100.000, dat Sun de 'point' in de 'dot Com' noemde.
De essentie is dat engineering in de echte wereld een compromis is, en de zakelijke realiteit is een deel van dat compromis. Ik bied mijn excuses niet aan voor het feit dat ik de voorkeur geef aan eten, en dat ik voldoende geld wil verdienen om op een dag met pensioen te kunnen gaan. Dit betekent op zijn beurt dat ik goed moet begrijpen hoe ik mijn werkgever ten minste tien keer meer waarde kan bieden dan mijn salaris. Als ik dat kan doen terwijl ik blijf werken met open source en andere bedrijven help geld te verdienen, zodat ze bereid zijn bij te dragen aan ext4, dan is dat een deel van de uitdaging en waarom ik houd van werken met open source.
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.
In sommige gevallen waren de zorgen ongegrond; bijvoorbeeld, Linus schreeuwde tegen een senior ontwikkelaar die echt 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 zich vaak afschrikt voelden: “Wat als Linus mij publiekelijk voor schut zet zoals hij deed met Steve?”, zonder te begrijpen dat dit in de praktijk niet zal gebeuren. Daarom hebben we een CoC; het is niet voor ons, senior ingenieurs, maar om jongere ingenieurs in onze teams te ondersteunen die we willen opleiden, zodat zij op een gegeven moment ons kunnen vervangen wanneer het tijd is om met pensioen te gaan, of wanneer ons een bus aanrijdt, of wanneer we op een andere manier deze sterfelijke wereld verlaten.
Vergeet niet dat er 50-100 man-jaren werk zijn besteed aan het creëren van een bestandssysteem dat klaar is voor gebruik in een zakelijke omgeving. We hebben alle ingenieurs nodig die we kunnen aantrekken, en velen van ons doen extra werk in hun vrije tijd, omdat het ons iets kan schelen. Het maken van een hoogwaardig bestandssysteem is teamwerk, en we hebben elke talentvolle ingenieur nodig die we kunnen binnenhalen. Zelfs als één ingenieur een super 10x programmeur is, als hij uiteindelijk een heleboel andere ingenieurs afschrikt die kunnen werken aan testen, prestatie-optimalisatie, etc., is het gewoon niet waard om iemand een hufter te laten zijn.
Bron: opennet.ru
