Oversættelse af tanker fra Theodore Ts’o (Theodore Ts’o), skaberen af filsystemet Ext4, om udviklingen af ext4, filsystemet BcacheFS, Linux-kernen, ZFS, adfærdskoden og filsystemer generelt:
Om udviklingen af ext4.
I hver udgave af kernen bidrager mere end et halvt dusin mennesker. I øjeblikket bruger jeg størstedelen af min tid på at gennemgå kode, køre tests og forbedre testapplikationen {kvm,gce,qemu,android}-xfstests. Og jeg er meget afhængig af 2-3 andre udviklere, der arbejder hos SUSE og IBM, som hjælper mig med kodegennemgang.
Om BcacheFS
Ærligt talt er bcachefs ikke et helt selvstændigt projekt - for eksempel var Kent forfatter til 72% af patches mellem versionerne 6.11 og 6.12 af kernen, mens der i alt var 103 patches til ext4 i samme periode, hvor jeg var forfatter til præcis 0%. Dette skyldes, at jeg er fast overbevist om, at programmering er en holdsport, og mit arbejde som teknisk leder handler om at give deltagerne i ext4 mulighed for at gøre alt, hvad de kan for at forbedre filsystemet. Vi holder ugentlige møder, og Derrick Wong, seniorudvikler for XFS og tidligere vedligeholder af XFS, deltager i disse møder - og som det er kendt, har jeg hjulpet ham med test af XFS, mens Derrick har hjulpet mig med forskellige spørgsmål om testning af ext4 og har endda gennemgået et par patches til ext4. Vi samarbejder med hinanden, og det er godt.
Jeg lader andre afgøre, om de vil stole på nogen, der er en ensom, dygtig programmør, som muligvis er mere talentfuld end jeg, men lad mig give dig et hint - du kan "snyde" ved at inddrage et team i at løse problemet. Det er ikke nødvendigt at gøre det alene. Selvfølgelig skal du vide, hvordan du vækker det bedste i andre, og du skal arbejde sammen. Og venlighed mod hinanden i mailinglisterne skader ikke.
Om kernen, CoC, mulighederne og fremtiden for ext4
Ext4 får faktisk nogle nye funktioner, men det er de funktioner, som virksomhederne er villige til at finansiere, fordi tilbagebetalingen af udviklingsomkostninger giver mening i forhold til omkostninger og fordele. For eksempel blev fscrypt og case-insensitive kataloger funktioner, der var nyttige for Android og Chrome OS, og blev finansieret, i det mindste delvist, af disse udviklergrupper (Steam var også bekymret for store bogstaver og støttede en af ingeniørerne). Vi ønsker at tilføje støtte til 'untorn' skrivning, fordi det vil forbedre ydeevnen for databaser på cloud-emulerede block-enheder, hvor 16k atomare skriver kan garanteres, hvilket vil eliminere behovet for dobbelt buffering i MySQL og PostgreSQL.
(Faktisk kan Amazon og Google gøre dette i deres egne DB-produkter ved at lave antagelser om, hvordan Amazon EBS og Google Persistent Disk fungerer, men vi ønsker at gøre det på en mere generel måde, som vil være mere bæredygtig på lang sigt). Dette er mindre attraktivt end ting som reflinks, men investeringsafkastet er meget lettere at retfærdiggøre, både fordi omkostningerne er lavere (mindre arbejde med udvikling, testning og kvalificering til virksomhedens deployment) og fordi fordelene er meget lettere at kvantificere. Ting som 'jeg kan spare omkostningerne til XX fuldtidsprogrammerere over fem år' er meget lettere at argumentere for med denne slags præstationsforbedrende funktioner.
I modsætning hertil er reflinks sjove, men jeg kunne ikke finde en kunde, der var villig til at dække udviklingsomkostningerne, eller en virksomhed, der tror, at deres kunder ville købe mere af deres produkt, hvis de tilføjede reflinks til ext4. Det kan virke ekstremt corporate, men der er en historie om, hvordan ZFS-ingeniører startede et projekt fra bunden, uden at spørge ledelsen til råds eller få forslag fra salgsafdelingen, og præsenterede Sun for, hvad der reelt var en fait accompli.
Det lyder godt, men når man husker på, at Sun til slut begyndte at tabe penge, indtil de blev tvunget til at sælge sig selv til et andet selskab, og at den tekniske organisation, der understøttede ZFS, ikke længere eksisterer. Omtrent samtidig med at ZFS blev annonceret, deltog jeg i en virksomhedsomfattende undersøgelse for at afgøre, om det gav mening at investere i filsystemfunktioner til AIX og Linux — og vi kom frem til, at det ikke gjorde, afkastet var lille, og nye filsystemfunktioner ville ikke føre til flere kunder, der købte hardware, software eller IBM-systemer. Måske har IBM oplevet svære tider, men den eksisterer stadig, mens Sun ikke gør.
Omtrent på samme tid mødtes repræsentanter fra flere Linux-virksomheder for at finde ud af, hvordan Linux ville kunne konkurrere med ZFS. Det var ved dette møde, at ideen blev fremsat om, at btrfs ville være det langsigtede svar, mens ext4 ville være en kortsigtet løsning, der ville sikre støtte til ting som realtidsændring af størrelse, 64-bit bloknumre og andre ting, der fandtes i traditionelle Legacy Unix OS, men som ikke var til stede i ext3.
På det møde blev jeg bedt om at definere, hvad der ville kræves for at skabe et helt nyt filsystem. Jeg gennemførte en undersøgelse og så på, hvor meget arbejde der var nødvendigt for at skabe filsystemer som IBM's GPFS og JFS, Digital's advfs, og vurderede hvor meget der var krævet af Sun for at skabe ZFS og bringe dette filsystem til en tilstand, der var klar til produktion. Det svar, jeg fik, lød på omkring 100 mand-år, med et lavt skøn på 50 mand-år og et højt skøn på 200 mand-år (men det var for GPFS, som var et klyngesystem, og derfor meget mere komplekst).
Jeg rapporterede dette på mødet, og en senior ingeniør fra Intel sagde: "Nej, fortæl ikke dette til ledelsen, for de vil aldrig godkende projektet! Fortæl dem, at btrfs vil være klar om 18 måneder." Jeg lader det være op til folk selv at afgøre, hvornår btrfs når status som "klar til erhvervsmæssig brug", især for de nye attraktive udvidede funktioner, der skulle konkurrere med ZFS, men jeg mener, at det ikke er til diskussion, at det ikke skete efter 18 måneder.
Og selv før Sun gik i opløsning, nægtede mange virksomheder, der sendte deres repræsentanter til mødet, at deres ingeniører kunne deltage i arbejdet med btrfs, og det hjalp selvfølgelig ikke. Men det var sandsynligvis relateret til, at virksomheder er rationelle organisationer, der træffer egne beslutninger om investeringsafkast, og finansieringen af et nyt filsystem gav ikke samme mening som at fortælle folk, at Linux ville have et svar på ZFS.
Ser man tilbage, kan man sige, at selvom ZFS havde disse virkelig fantastiske funktioner, var de ikke tilstrækkelige til at få de fleste brugere til at vælge Solaris frem for at købe langt billigere x86-platforme og installere Linux. Og på det tidspunkt, hvor Sun besluttede at prøve strategien med OpenSolaris og Solaris x86, var det for sent. Nettovirkningen var enorm, og strategien for x86 svarede ikke på spørgsmålet om, hvordan én virksomhed, Sun, kunne betale løn til alle de super talentfulde ingeniører, der arbejdede på Solaris. At købe en x86-server til 5000 dollars giver ikke meget salgsrentabilitet sammenlignet med serveren SunFire E10k Sparc til 100000 dollars, som Sun kaldte «pointen» i «dot Com».
Essensen er, at ingeniørarbejde i den virkelige verden er et kompromis, og forretningsrealiteterne er en del af dette kompromis. Jeg undskylder ikke for, at jeg foretrækker at spise mad, og at jeg ønsker at tjene nok penge til en dag at gå på pension. Og det betyder i sin tur, at jeg skal forstå, hvordan jeg skaber værdi for min arbejdsgiver, mindst ti gange min løn. Hvis jeg kan gøre det, mens jeg arbejder med open source og hjælper andre virksomheder med at tjene penge, så de er villige til at bidrage til ext4, jamen, det er en del af udfordringen og grunden til, at jeg elsker at arbejde med open source.
Og når jeg vender tilbage til adfærdskodeksen, vil jeg sige, at næsten alle vedligeholdere af de vigtigste filsystemer støttede kodeksen ikke af svage liberale årsager. Det er fordi, vi har brug for hver ingeniør, der er villig til at bidrage til vores projekt, og de fleste af os har set personer, der nægtede at arbejde med Linux og skiftede til andre operativsystemer (jeg kender en person, der skiftede til Windows og var en værdifuld Linux-kerneudvikler i IBM Linux Technology Center) eller arbejdede på interne projekter, men ikke på det, der krævede interaktion med LKML, på grund af den toksiske atmosfære fra enkelte personer på mailinglisten.
I nogle tilfælde var bekymringerne ubegrundede; for eksempel råbte Linus ad en seniorudvikler, der faktisk burde have vidst bedre, og som Linus personligt mødte de fleste gange, og de havde allerede etablerede forhold. Problemet er, at nybegyndere ikke vidste dette og blev skræmt — „hvad nu hvis Linus ydmyger mig offentligt ligesom han gjorde med Steve“, uvidende om at det i praksis ikke ville ske. Det er derfor, vi har CoC; det er ikke for os senioringeniører, men for at støtte de yngre ingeniører i vores teams, som vi ønsker at træne, så de på et tidspunkt kan erstatte os, når tid til pensionering kommer, eller vi bliver ramt af en bus, eller vi på anden måde forlader denne verden.
Glem ikke de 50-100 personår, der er brugt på at skabe et filsystem, der er klar til brug i et virksomhedsmiljø. Vi har brug for alle ingeniører, vi kan tiltrække, og mange af os udfører ekstra arbejde i vores fritid, fordi vi ikke er ligeglade. At skabe et højtkvalitets filsystem er et teamwork, og vi har brug for hver talentfuld ingeniør, vi kan få. Selv hvis en ingeniør er en super 10x programmør, hvis det i sidste ende skræmmer en masse andre ingeniører, der kunne arbejde på testning, performance tuning osv., er det bare ikke det værd at lade nogen være en skurk.
Kilde: opennet.ru
