ĂversĂ€ttning av Theodore Tsâos tankar om utvecklingen av ext4, filsystemet BcacheFS, Linux-kĂ€rnan, ZFS, uppförandekoden och filsystem generellt:
Om utvecklingen av ext4.
I varje version av kÀrnan bidrar mer Àn ett dussin personer. För nÀrvarande gÄr en stor del av min tid Ät till att granska kod, utföra tester och förbÀttra testapplikationen {kvm,gce,qemu,android}-xfstests. Och jag förlitar mig mycket pÄ 2-3 andra utvecklare som arbetar pÄ SUSE och IBM som hjÀlper mig med granskningen av koden.
Om BcacheFS
Ărligt talat Ă€r bcachefs inte ett helt fristĂ„ende projekt â till exempel var Kent författare till 72% av patcharna mellan versionerna 6.11 och 6.12 av kĂ€rnan, medan jag för min del var författare till exakt 0% av de 103 patcharna till ext4 under samma tidsperiod. Detta beror pĂ„ att jag fast för hĂ„ller att programmering Ă€r en lagsport, och min uppgift som teknisk ledare Ă€r att ge deltagarna i ext4 möjlighet att göra allt de kan för att förbĂ€ttra filsystemet. Vi har veckovisa konferenser, och Derrick Wong, seniorutvecklare för XFS och tidigare underhĂ„llare av XFS, deltar i dessa konferenser â och jag har tydligt hjĂ€lpt honom med frĂ„gor kring testning av XFS, medan Derrick har hjĂ€lpt mig med olika frĂ„gor kring testning av ext4 och till och med granskat ett par patchar för ext4. Vi samarbetar med varandra, och det Ă€r bra.
Jag lĂ„ter andra avgöra om de vill lita pĂ„ nĂ„gon som Ă€r en ensamstĂ„ende, passionerad programmerare, som kanske Ă€r mer begĂ„vad Ă€n jag, men jag ger er en ledtrĂ„d â ni kan "fuska" genom att involvera ett team i att lösa problemet. Det Ă€r inte nödvĂ€ndigt att göra det ensam. SjĂ€lvklart mĂ„ste ni veta hur ni ska vĂ€cka det bĂ€sta i andra, och ni mĂ„ste samarbeta. Och ett artigt förhĂ„llande till varandra i mailinglistor skadar inte.
Om kÀrnan, CoC, möjligheter och framtiden för ext4
Ext4 fÄr verkligen nÄgra nya funktioner, men det Àr sÄdana som företagen Àr villiga att finansiera, eftersom avkastningen pÄ utvecklingen av funktionen Àr meningsfull utifrÄn kostnad och nytta. Till exempel var fscrypt och kataloger utan beaktande av register funktioner som var anvÀndbara för Android och Chrome OS, och dessa finansierades, Ätminstone delvis, av dessa utvecklargrupper (Steam oroade sig ocksÄ för registrering och stödde en av ingenjörerna). Vi vill lÀgga till stöd för oavbruten skrivning (untorn), eftersom det kommer att förbÀttra prestandan för databaser pÄ moln-emulerade blockenheter, dÀr 16k atomÀra poster kan garanteras, vilket skulle eliminera behovet av dubbel buffring i MySQL och PostgreSQL.
(Faktiskt kan Amazon och Google göra detta i sina egna DB-produkter genom att göra antaganden om hur Amazon EBS och Google Persistent Disk fungerar, men vi vill göra det pÄ ett mer allmÀnt sÀtt, vilket kommer att vara mer hÄllbart pÄ lÄng sikt). Det Àr mindre attraktivt Àn sÄdana saker som reflinks, men avkastningen pÄ investeringen Àr mycket lÀttare att motivera, bÄde dÀrför att kostnaderna Àr lÀgre (mindre arbete med utveckling, testning och kvalificering för företagsutveckling) och dÀrför att fördelarna Àr mycket lÀttare att kvantifiera. Saker som "jag kan spara kostnaden för löner för XX anstÀllda ingenjörer under fem Är" Àr mycket lÀttare att göra för den hÀr typen av prestandafunktioner.
I motsats till detta Àr reflinks roliga, men jag kunde inte hitta en kund villig att betala utvecklingskostnaderna eller ett företag som anser att deras kunder skulle köpa mer av deras produkt om de lade till reflinks i ext4. Detta kan verka oerhört företagsinriktat, men det finns en historia om hur ZFS-ingenjörer började ett projekt frÄn grunden, utan att frÄga ledningen om lov och utan förslag frÄn försÀljningsavdelningen, och presenterade för Sun vad som i praktiken var ett fullbordat faktum.
Det lĂ„ter bra, men om man tĂ€nker pĂ„ att Sun slutligen började förlora pengar, tills de var tvungna att sĂ€lja sig till ett annat företag, och att den ingenjörsorganisation som stödde ZFS faktiskt inte lĂ€ngre finns. UngefĂ€r vid den tidpunkt dĂ„ ZFS tillkĂ€nnagavs deltog jag i en företagsomfattande studie för att ta reda pĂ„ om det var meningsfullt att investera i filsystemsfunktioner för AIX och Linux â och vi kom fram till att det inte var det; avkastningen pĂ„ investeringen var liten och de nya filsystemsfunktionerna skulle inte leda till fler kunder som köpte hĂ„rdvara, mjukvara eller IBM-system. Kanske var det tuffa tider för IBM, men de finns fortfarande kvar, medan Sun inte gör det.
UngefÀr vid samma tidpunkt samlades representanter frÄn flera Linux-företag för att diskutera hur Linux skulle konkurrera med ZFS. Vid detta möte föreslogs tanken att btrfs skulle vara det lÄngsiktiga svaret, medan ext4 skulle vara en kortsiktig lösning som skulle ge stöd för funktioner som realtidsÀndring av storlek, 64-bitars blocknummer och andra funktioner som fanns i traditionella Legacy Unix OS och som inte fanns i ext3.
Vid det mötet blev jag ombedd att definiera vad som skulle krÀvas för att skapa ett helt nytt filsystem. Jag genomförde en undersökning och tittade pÄ hur mÄnga resurser som krÀvdes för att skapa filsystem som IBM:s GPFS och JFS, sÄvÀl som advfs frÄn Digital, och bedömde hur mycket Sun hade behövt för att skapa ZFS och fÄ detta filsystem till ett helt produktionsklart tillstÄnd. Det svar jag fick var ungefÀr 100 personÄr, med en lÄg uppskattning pÄ 50 personÄr och en hög uppskattning pÄ 200 personÄr (men detta var för GPFS, som var ett klusterfilsystem och dÀrför mycket mer komplext).
Jag rapporterade detta pÄ mötet, och en senior ingenjör frÄn Intel sade: "Nej, prata inte om detta med cheferna, för de kommer aldrig att godkÀnna projektet! SÀg till dem att btrfs kommer att vara klart om 18 mÄnader." Jag lÄter folk sjÀlva avgöra nÀr btrfs nÄr statusen "fÀrdig för företagsanvÀndning", sÀrskilt för de nya attraktiva utvidgade funktionerna som skulle konkurrera med ZFS, men jag tror inte att det Àr vÀrt att diskutera att detta skedde inte inom 18 mÄnader.
Och redan innan Sun splittrades valde mÄnga företag, som skickade sina representanter till mötet, att inte lÄta ingenjörerna delta i arbetet med btrfs, och det hjÀlpte förstÄs inte. Men det berodde förmodligen pÄ att företagen Àr rationella organisationer som fattar egna beslut om avkastning pÄ investeringar, och att finansiera ett nytt filsystem inte hade samma mening som att berÀtta för folk att Linux skulle ha ett svar pÄ ZFS.
Ser man tillbaka kan man sÀga att Àven om ZFS hade dessa riktigt coola funktioner, var de inte tillrÀckliga för att fÄ de flesta anvÀndare att vÀlja Solaris över att köpa mycket billigare x86-plattformar och installera Linux. Och vid den tidpunkten dÄ Sun beslutade att prova strategin OpenSolaris och Solaris x86, var det för sent. NÀtverkseffekterna var enorma, och strategin för x86 gav inget svar pÄ hur ett företag, Sun, kunde betala lön till alla de supertalangfulla ingenjörerna som arbetade med Solaris. Att köpa en x86-server för 5000 dollar ger ingen stor avkastning pÄ försÀljningen jÀmfört med servern SunFire E10k Sparc för 100000 dollar, som Sun kallade "punkten" i "dot Com".
PoÀngen Àr att ingenjörsarbete i verkliga vÀrlden Àr en kompromiss, och affÀrsrealiteter Àr en del av den kompromissen. Jag ber inte om ursÀkt för att jag föredrar att Àta mat, och att jag vill tjÀna tillrÀckligt med pengar för att en dag kunna gÄ i pension. Och det innebÀr Ä sin sida att jag mÄste förstÄ hur jag tillför arbetsgivaren vÀrde, Ätminstone tio gÄnger mer Àn min lön. Om jag kan göra det och fortsÀtta arbeta med öppen kÀllkod och hjÀlpa andra företag att tjÀna pengar sÄ att de Àr villiga att bidra till ext4, ja, det Àr en del av utmaningen och varför jag Àlskar att arbeta med öppen kÀllkod.
Och tillbaka till uppförandekoden, jag vill sÀga att nÀstan alla underhÄllare för de viktigaste filsystemen stöder koden inte av nÄgra vaga liberala skÀl. Det beror pÄ att vi behöver varje ingenjör som Àr redo att bidra till vÄrt projekt, och de flesta av oss har sett mÀnniskor som vÀgrar att arbeta med Linux och gÄr över till andra operativsystem (jag kÀnner en person som bytte till Windows och var en vÀrdefull utvecklare av Linux-kÀrnan vid IBM Linux Technology Center) eller arbetar med interna projekt, men inte med sÄdant som krÀver interaktion med LKML, pÄ grund av den giftiga miljön av nÄgra personer i e-postlistan.
I vissa fall var farhĂ„gorna obefogade; till exempel skrek Linus pĂ„ en seniorutvecklare som verkligen borde ha vetat bĂ€ttre och som Linus i de flesta fall hade trĂ€ffat personligen, och de hade redan etablerade relationer. Problemet Ă€r att nykomlingar inte visste detta och blev skrĂ€mda â "tĂ€nk om Linus förnedrar mig offentligt som han gjorde med Steve", utan att förstĂ„ att detta i praktiken inte skulle hĂ€nda. Det Ă€r dĂ€rför vi har CoC; det Ă€r inte för oss, senioringenjörer, utan för att stödja yngre ingenjörer i vĂ„ra team, som vi vill utbilda sĂ„ att de vid ett visst tillfĂ€lle kan ersĂ€tta oss nĂ€r det Ă€r dags att gĂ„ i pension, eller nĂ€r en buss kör över oss, eller vi pĂ„ annat sĂ€tt lĂ€mnar denna dödliga vĂ€rld.
TĂ€nk pĂ„ 50-100 personĂ„r av arbete för att skapa ett filsystem redo att anvĂ€ndas i företagsmiljö. Vi behöver alla ingenjörer vi kan fĂ„, och mĂ„nga av oss arbetar extra pĂ„ sin fritid, för att vi bryr oss. Att skapa ett högkvalitativt filsystem Ă€r ett lagarbete, och vi behöver varje begĂ„vad ingenjör som vi kan fĂ„ tag pĂ„. Ăven om en ingenjör Ă€r en super 10x programmerare, om han i slutĂ€ndan skrĂ€mmer ivĂ€g mĂ„nga andra ingenjörer som kan arbeta med testning, prestandaoptimering osv., sĂ„ Ă€r det helt enkelt inte vĂ€rt det att lĂ„ta nĂ„gon vara en skurk.
KĂ€lla: opennet.ru
