Theodore Ts'o märkmed Linuxi tuumast, käitumiskoodeksist, ext4, btrfs ja ZFS-ist

Theodore Ts’o (Teodor Ts’o), ext4 failisüsteemi looja, mõtiskluste tõlge ext4 arendamisest, BcacheFS failisüsteemist, Linuxi tuumast, ZFS-ist, käitumiskoodeksist ja failisüsteemidest üldiselt:

Ext4 arendamisest.

Iga ext4 tuuma väljaande arendusse panustavad üle poole tosinast inimest. Praegu kulub suur osa minu ajast koodi ülevaatamisele, testimisele ja testimisrakenduse täiustamisele {kvm,gce,qemu,android}-xfstests. Ja ma toetan end väga 2-3 teise arendaja tööle, kes töötavad SUSE ja IBM-is, kes aitavad mind koodi ülevaatamisel.

BcacheFS-ist

Ausalt öeldes ei ole bcachefs täielikult üksik projekt — näiteks oli Kent autori õigusi 72% patšidest tuuma väljaannete 6.11 ja 6.12 vahel, samas kui ext4 jaoks sama ajavahemiku jooksul olin mina autori õigusi 0%. See on seepärast, et ma olen kindlalt veendunud, et programmeerimine on meeskonnatöö ja minu töö tehnilise juhina on anda ext4 osalistele võimalus anda endast parim failisüsteemi täiustamiseks. Me korraldame iganädalasi konverentse ja Derrick Wong, XFS-i vanem arendaja ja endine XFS-i hooldaja, osaleb nendel konverentsidel — ja ma olen tuntud kui abiline XFS-i testimise küsimustes, samas kui Derrick aitas mind erinevates ext4 testimise küsimustes ja isegi vaatas läbi paar ext4 patši. Me teeme koostööd ja see on hea.

Ma lasen teistel otsustada, kas nad soovivad usaldada oma andmeid kellelegi, kes on üksik kuum programmeerija, kes võib olla andekam kui mina, kuid annan teile vihje — te saate „pettuda“, kaasates meeskonna probleemi lahendamisse. Pole vajalik teha seda üksi. Loomulikult peate teadma, kuidas teistes parimat esile tuua, ja peate koos töötama. Ja viisakas suhtumine üksteisse meilistes ei tee ka paha.

Kernist, CoC-ist, võimalustest ja ext4 tulevikust

Ext4 tõepoolest saab uusi funktsioone, kuid need on need, mida ettevõtted on valmis rahastama, kuna funktsiooni arendamise tasuvus on mõistlik kulude ja kasu seisukohalt. Näiteks oli fscrypt ja juhtumid, kus ei arvestata suurtähti, funktsioonid, mis olid kasulikud Androidile ja Chrome OS-ile, ning need finansseerisid vähemalt osaliselt need arendajate rühmad (ka Steam muretses suurtähti ignoreerimise pärast ja toetas ühte inseneri). Soovime lisada katkematu kirjutamise (untorn) toe, kuna see parandab andmebaaside jõudlust pilveemuleeritavatel plokkseadmetel, kus saab garanteerida 16k aatomkirjeid, võimaldades elimineerida kahekordse vahemälu MySQL-is ja PostgreSQL-is.

(Tegelikult saavad Amazon ja Google seda teha oma andmebaasi tootes, tehes oletusi selle kohta, kuidas toimivad Amazon EBS ja Google Persistent Disk, kuid soovime seda teha üldisemalt, mis on pikaajaliselt paremini toetatav). See ei ole nii atraktiivne kui sellised asjad nagu reflinks, kuid investeeringute tasuvus on palju lihtsam põhjendada, kuna kulud on madalamad (vähem töötlust, testimist ja kvalifitseerimist ettevõtte kasutuse jaoks), samuti on eeliseid kergem kvantitatiivselt hinnata. Asjad nagu "ma saan säästa XX programmeerimise inseneride palkasid viis aastat", on selliste jõudluse tõstmise funktsioonide puhul palju kergemad.

Selle vastu on reflinks lõbusad, kuid ma ei suutnud leida klienti, kes oleks valmis arenduskulusid katma, või ettevõtet, kes arvaks, et nende kliendid ostaksid rohkem nende toodet, kui nad lisavad reflinks ext4-le. See võib tunduda kohutavalt korporatiivne, kuid on lugu sellest, kuidas ZFS-i insenerid alustasid projekti nullist, küsides juhtkonnalt luba ja saamata müügiosakonnalt ettepanekuid, ning tutvustasid Sunile seda, mis tegelikult oli toimunud fakt.

Kuulub suurepäraselt, kuid kui meenutada, et lõpuks hakkas Sun raha kaotama, kuni nad pidid ennast teisele ettevõttele müüma, ja tegelikult ei eksisteeri ZFS-i toetav inseneriorganisatsioon enam. Umbes sel ajal, kui ZFS välja kuulutati, osalesin ma kogu ettevõtte uuringus, et uurida, kas on mõttekas investeerida failisüsteemi funktsioonidesse AIX-is ja Linuxis - ning jõudsime järeldusele, et ei, investeeringutasuvus on madal ja uued failisüsteemi funktsioonid ei toovad kaasa klientide arvu kasvu, kes ostavad riistvara, tarkvara või IBM-i süsteeme. Võib-olla olid IBM-il rasked ajad, kuid nad eksisteerivad endiselt, Sun aga mitte.

Sel ajal kogunesid mitmete Linuxi ettevõtete esindajad, et välja mõelda, kuidas Linux ZFS-iga võistlema hakkab. Just selles kohtumises esitati idee, et btrfs on pikaajaline lahendus, samas kui ext4 on lühiajaline lahendus, mis toetab selliseid asju nagu reaalajas suuruse muutmine, 64-bitised plokkinumbrid ja muud asjad, mis olid traditsioonilistes Legacy Unix OS-is, kuid ei olnud ext3-s.

Selles kohtumises paluti mul määratleda, mida on vaja täiesti uue failisüsteemi loomiseks. Ma tegin uuringu, vaadates, kui palju vaeva oli vaja selliste failisüsteemide, nagu IBM-i GPFS ja JFS, Digitali advfs loomiseks, hinnates, kui palju Sun kulutas ZFS-i loomisele ja selle failisüsteemi tootmisse viimisele. Vastus, mille ma sain, oli umbes 100 inimeset aastat, kusjuures madalaim hindamine oli 50 inimeset aastat ja kõrgeim hindamine 200 inimeset aastat (aga see oli GPFS-i jaoks, mis oli klastrifailisüsteem ja seetõttu palju keerulisem).

Teatasin sellest koosolekul, ja üks Intel'i vaneminsener ütles: „Ei, ärge rääkige sellest juhtidele, sest nad ei kiida projekti kunagi heaks! Öelge neile, et btrfs on valmis 18 kuu pärast.” Ma luban inimestel ise otsustada, millal btrfs saavutab „ettevõtte kasutuse valmisoleku” staatuse, eriti nende uute atraktiivsete täiendavate funktsioonide jaoks, mis pidid konkurentideks olema ZFS-ile, kuid ma ei arva, et arutelu alla kuulu oleks, et see ei juhtunud 18 kuu jooksul.

Ja enne kui Sun lagunes, keelasid paljude ettevõtete esindajad, kes osalesid koosolekul, inseneride kaasamise btrfs arendamisse, mis loomulikult ei aidanud olukorda. Kuid tõenäoliselt oli see seotud sellega, et ettevõtted on ratsionaalsed organisatsioonid, kes teevad oma investeeringute tasuvuse otsused ning uue failisüsteemi rahastamine ei olnud sama mõttekas kui rääkida inimestele, et Linuxil on vastus ZFS-ile.

Tagasi vaadates võib öelda, et kuigi ZFS-il olid mõned tõeliselt head funktsioonid, ei olnud need piisavad, et sundida enamiku kasutajaid valima Solaris x86 ostmise asemel palju odavamaid x86 platvorme ja Linuxi installimist. Ja kui Sun otsustas proovida OpenSolaris ja Solaris x86 strateegiat, oli juba liiga hilja. Võrguefektid olid tohutud ning x86 strateegia ei andnud vastust küsimusele, kuidas üks ettevõte, Sun, suudaks maksta palku kõigile neile üliandekatele inseneridele, kes töötasid Solarisel. 5000 dollari eest x86-serveri ostmine ei too suurt kasumimarginaali võrreldes serverilt 100 000 dollari maksva SunFire E10k Sparciga, mida Sun nimetas 'punktiks' 'dot Com' aega.

Asi on selles, et inseneritöö reaalses maailmas on kompromiss ja ärireaalsused on osa sellest kompromissist. Ma ei vabanda selle eest, et eelistan süüa toitu ja et soovin teenida piisavalt raha, et ühel päeval pensionile jääda. See tähendab, et pean hästi mõistma, kuidas ma oma tööandjale vähemalt kümme korda suuremat kasu toon kui minu palk. Kui ma suudan seda teha, töötades samal ajal avatud lähtekoodiga ja aidates teistel ettevõtetel raha teenida, et nad oleksid valmis panustama ext4-sse, siis see on osa väljakutsest ja põhjus, miks mulle avatud lähtekoodiga töötamine meeldib.

Ja, rääkides käitumiskoodist, ütlen, et peaaegu kõik peamiste failisüsteemide hooldajad toetasid Koodi mitte mingite nõrkade liberaalsete kaalutluste tõttu. See on sellepärast, et me vajame iga inseneri, kes on valmis meie projektiga panustama, ja enamus meist on näinud inimesi, kes keeldusid Linuxiga töötamast ja läksid üle teistele operatsioonisüsteemidele (ma tean ühte inimest, kes läks Windowsi ja oli väärtuslik Linuxi kernel arendaja IBM Linux Technology Centeris) või töötasid sisemiste projektide kallal, aga mitte nende kallal, mis nõudsid suhtlemist LKML-iga, kuna mõne inimeste toksiline keskkond postitusloendis.

Mõnes olukorras olid mured põhjendamatud; näiteks karjus Linus vanema arendaja peale, kes tegelikult pidi paremini teadma ja kellel olid enamikul juhtudel isiklikud kohtumised Linusega ning neil olid juba väljakujunenud suhted. Probleem on selles, et algajad ei teadnud seda ja kartsid — "kuidas kui Linus alandab mind avalikult sama, nagu ta tegi Steve'iga", mõistmata, et praktikas seda ei juhtu. Just seetõttu on meil CoC; see ei ole meie, vanemate inseneride jaoks, vaid nooremate inseneride toetamiseks meie meeskondades, keda me tahame koolitada, et nad asendaksid meid mingil hetkel, kui on aeg pensionile jääda, või kui meid sõidab auto üle, või me lahkume sellelt maailmalt muul viisil.

Ärge unustage 50-100 inimesetöö aastat, mis on kulutatud failisüsteemi loomisele, mis on valmis kasutamiseks ettevõtte keskkonnas. Me vajame kõiki insenere, keda saame kaasata, ja paljud meist teevad lisatööd oma vabal ajal, sest me ei ole ükskõiksed. Kvaliteetse failisüsteemi loomine on meeskonnatöö ja me vajame iga andeka inseneri, keda suudame saada. Isegi kui üks insener on super 10-kordne programmeerija, kui ta lõpuks peletab eemale hulga teisi insenere, kes võiksid testimise, jõudluse häälestamise jne kallal töötada, ei tasu see lihtsalt ära, et lasta kellegil olla tõbras.

Allikas: opennet.ru