Theodore Ts'o mõtiskluste tõlge (Theodore Ts’o), Ext4 failisüsteemi looja, ext4 arendamisest, BcacheFS failisüsteemist, Linuxi kernelist, ZFS-ist, käitumiskoodeksist ja failisüsteemidest laiemalt:
ext4 arendamisest.
Iga ext4 tuuma väljalaske eest kannavad hoolt üle poole tosina inimese. Praegu kulub suurem osa minu ajast koodi ülevaatamiseks, testimiseks ja testrakenduse täiustamiseks {kvm,gce,qemu,android}-xfstests. Ja ma toetun väga 2-3 muule arendajale, kes töötavad SUSE-s ja IBM-is, kes aitavad mind koodi ülevaatamisel.
BcahceFS-ist
Ausustades, bcachefs ei ole täielikult iseseisev projekt — näiteks Kent oli 6.11 ja 6.12 kärbeste vahel 72% patššide autor, samas kui ext4 103 patši seast olin ma autoriks täpselt 0%. See on seetõttu, et ma usun kindlalt, et programmeerimine on meeskonnatöö ja minu ülesanne tehnilise juhtina on võimaldada ext4 osalejatel anda endast parim failisüsteemi parandamiseks. Me korraldame iganädalasi koosolekuid, millest võtab osa Derrick Wong, XFS vanem arendaja ja endine XFS hooldaja — ning nagu on teada, olen ma teda aidanud XFS testimise küsimustes ning Derrick on aidanud mind erinevates ext4 testimise küsimustes ja isegi vaadanud mõningaid ext4 patšše. Me teeme koostööd ja see on hea.
Ma annan teistele inimestele valida, kas nad usaldavad oma andmed kellegi juurde, kes on üksik kuum programmeerija, kes võib olla palju andekam kui mina, kuid annan teile vihje — te saate "pettuse" tehes meeskonna kaasata probleemi lahendamisse. Te ei pea seda üksi tegema. Muidugi, selleks peate teadma, kuidas teiste parimaid külgi esile tuua ja te peate koostööd tegema. Ja omavaheline viisakus meililistides ei tee kunagi paha.
Kernist, CoC-st, võimalustest ja tulevikust ext4
Ext4 omab tõepoolest uusi funktsioone, kuid need on need, mida ettevõtted on valmis rahastama, kuna funktsiooni arendamise tasuvus on kulude ja kasu vaates mõistlik. Näiteks olid fscrypt ja registreerimata kataloogid funktsioonid, mis olid kasulikud Androidile ja Chrome OS-ile ning neid rahastati vähemalt osaliselt nende arendajate rühmade poolt (Steam oli samuti mures registreerimise kõrvaldamise pärast ja toetas ühte inseneri). Soovime lisada katkematu kirjutamise (untorn) toe, kuna see parandab andmebaaside jõudlust pilve emuleeritud plokkseadmetes, kus saab tagada 16k aatomlisandit, võimaldades MySQL ja PostgreSQL topeltpuhverdamisest vabaneda.
(Tegelikult saavad Amazon ja Google seda teha oma andmebaasitoodetes, tehes oletusi selle kohta, kuidas töötavad Amazon EBS ja Google Persistent Disk, kuid me tahame seda teha üldisemal viisil, mis oleks pikas perspektiivis paremini toetatav). See on vähem ahvatlev kui sellised asjad nagu reflinks, kuid investeeringu tasuvus on palju kergem põhjendada, nii madalamate kulude tõttu (vähem arendustööd, testimist ja kvalifitseerimist ettevõtte kasutuselevõtuks) kui ka seetõttu, et eeliseid on lihtsam kvantitatiivselt hinnata. Sellised asjad nagu 'ma võin säästa XX palga maksmise insenerprogrammeerija töötasu viie aasta jooksul' on palju kergemini saavutatavad selliste tootlikkuse suurendamise funktsioonide puhul.
Teistsuguste vahel on reflinks lõbus, kuid ma ei suutnud leida ühtegi klienti, kes oleks nõus arenduskulusid katma, ega ka ettevõtet, kes usuks, et nende kliendid ostavad rohkem tooteid, kui nad lisavad reflinks'i ext4-le. See võib tunduda äärmiselt korporatiivne, kuid on lugu, kuidas ZFS-i insenerid alustasid projekti tühjalt kohalt, küsides nõusolekut juhtkonnalt ja saamata müügiosakonnalt sisendeid ning esitlesid Sunile seda, mis oli tegelikult juba loodud fakt.
Kõlab hästi, kuid kui meenutada, et lõpuks hakkas Sun raha kaotama, kuni nad pidid end teisele ettevõttele müüma, ja tegelikult ei eksisteeri ZFS-i toetav inseneriorganisatsioon enam. Umbes sel ajal, kui ZFS välja kuulutati, osalesin ma terve ettevõtte ulatuses uuringus, et kaaluda, kas investeerimine failisüsteemi funktsioonidesse AIX-i ja Linuxi jaoks on mõtet — ja jõudsime järeldusele, et ei, investeeringute tasuvus on väike ning uued failisüsteemi funktsioonid ei too enam kliente, kes ostaksid riistvara, tarkvara või IBM-i süsteeme. Võib-olla oli IBM-il rasked ajad, kuid nad eksisteerivad ikka veel, samas kui Sun ei ole.
Umbes sel ajal kogunesid mitmete Linuxi ettevõtete esindajad, et arutada, kuidas Linux ZFS-iga konkureerida võiks. Just sellel kohtumisel tekkis idee, et btrfs on pikaajaline lahendus, samas kui ext4 on lühiajaline lahendus, mis tagab selliste asjade toe nagu reaalajas suuruse muutmine, 64-bitised plokknumbrid ja muud asjad, mis olid traditsioonilistes Legacy Unix OS-ides, kuid puudusid ext3-l.
Sel kohtumisel paluti mul määrata, mida on vaja täiesti uue failisüsteemi loomiseks. Uurisin, kui palju jõupingutusi kulus selliste failisüsteemide nagu IBM-i GPFS ja JFS, Digitali advfs loomiseks, hindasin, kui palju kulus Sunil ZFS-i loomiseks ja selle failisüsteemi viimiseks tootmisvalmidusse. Vastus, mille sain, oli umbes 100 inimeseaastat, ühe madala hinnanguga 50 inimeseaastat ja kõrge hinnanguga 200 inimeseaastat (aga see oli GPFS-i jaoks, mis oli klastriline failisüsteem ja seetõttu palju keerulisem).
Teatasin sellest koosolekul, ja üks Intel'i vanem insener ütles: „Ei, ärge rääkige sellest juhtidele, sest nad ei kiida projekti kunagi heaks! Öelge neile, et btrfs on valmis 18 kuu pärast.” Annan inimestele ise otsustada, millal btrfs saavutab staatuse „valmis ettevõtte kasutamiseks”, eriti nende uute atraktiivsete laiendatud funktsioonide osas, mis pidid konkureerima ZFS-iga, kuid ma ei arva, et on arutamisruumi selle üle, et see juhtus mitte 18 kuu jooksul.
Ja isegi enne, kui Sun lagunes, keeldusid paljud ettevõtted, kes saatsid oma esindajad kohtumisele, laskmast insenere btrfs-i arendusse kaasata, ja see ei aidanud kindlasti. Kuid tõenäoliselt oli see tingitud sellest, et ettevõtted on ratsionaalsed organisatsioonid, kes teevad oma investeeringutasuvuse kohta otsuseid, ja uue failisüsteemi rahastamine ei olnud sama mõistlik kui rääkida inimestele, et Linuxil on vastus ZFS-ile.
Tagasi vaadates võib öelda, et ehkki ZFS-il oli tõeliselt lahe funktsioone, ei olnud need piisavad, et veenda enamikku kasutajatest valima Solarist võrreldes palju odavamate x86 platvormide ostmise ja Linuxi installimisega. Ja sel ajal, kui Sun otsustas proovida OpenSolaris ja Solaris x86 strateegiat, oli juba liiga hilja. Võrguefektid olid tohutud ja x86 strateegia ei pakkunud vastust küsimusele, kuidas üks ettevõte, Sun, suudaks palgata kõiki neid ülipalju andekaid insenere, kes töötasid Solarisel. 5000 dollari eest x86-serveri ostmine ei anna suurt müügikasumi tasuvust võrreldes serveriga 100 000 dollari eest SunFire E10k Sparciga, mida Sun nimetas „punktiks” „dot Com” aegadel.
Küsimus on selles, et inseneritegevus reaalses maailmas on kompromiss ja äritegevuse reaalsused on osa sellest kompromissist. Ma ei vabanda selle eest, et eelistan süüa head toitu ja tahan teenida piisavalt raha, et ühel päeval pensionile jääda. See tähendab omakorda, et pean hästi aru saama, kuidas ma toodan tööandjale kasu, mis vähemalt kümme korda ületab minu palka. Kui ma suudan seda teha, jätkates avatud lähtekoodiga töötamist ja aidates teistel ettevõtetel raha teenida, et nad oleksid valmis panustama ext4, siis see on osa väljakutsest ja see on põhjus, miks mulle avatud lähtekoodiga töötamine meeldib.
Ja, kui naasta käitumiskoodeksi juurde, siis ütlen, et peaaegu kõik peamiste failisüsteemide hooldajad toetasid koodeksi mitte mingite väsinud liberaalsete kaalutluste tõttu. See on seetõttu, et me vajame iga inseneri, kes on valmis meie projekti panustama, ja enamik meist on näinud inimesi, kes keeldusid Linuxiga töötamast ja läksid üle teistele operatsioonisüsteemidele (ma tean ühte isikut, kes läks Windowsile ja oli väärtuslik Linuxi kerneli arendaja IBM Linux Technology Center'is) või töötasid sisemiste projektide kallal, kuid ei tegelenud sellega, mis nõudis LKML-iga suhtlemist, kuna paaris inimese keskkond on olnud toksiline postitusloendis.
Mõnel juhul olid hirmud alusetud; näiteks karjus Linus vanema arendaja peale, kes tõeliselt pidi parem olema ja kellega Linus kohtus enamikul juhtudel isiklikult ning kellel olid juba loodud suhted. Probleemiks oli see, et algajad ei teadnud seda ja kartsid — "aga äkki alandab Linus mind avalikult nagu Steve'i puhul", ilma et nad mõistaksid, et praktikas seda ei juhtu. Just sellepärast on meil CoC; see ei ole meie, kogenud inseneride jaoks, vaid selleks, et toetada nooremaid insenere meie meeskondades, kellele me tahame õpetada, et nad mingil hetkel meid asendaksid, kui tuleb aeg pensionile jääda, või buss sõidab meid alla, või lahkume me muul moel sellest surelikust maailmast.
Ärge unustage, et selle ettevõtte tasemel kasutamiseks mõeldud failisüsteemi loomiseks on vajalik 50–100 inimese aasta tööd. Me vajame kõiki insenere, keda suudame kaasata, ja paljud meist teevad lisatööd oma vabal ajal, sest me ei ole ükskõiksed. Kvaliteetse failisüsteemi loomine on meeskonna töö ning igat andekat inseneri, keda saame hankida, on vaja. Isegi kui üks insener on super 10-kordne programmeerija, ei ole kasu sellest, kui ta tõukab eemale palju teisi insenere, kes saavad töötada testimise, jõudluse seadistamise jne kallal; see pole lihtsalt seda väärt, et lasta kellelgi olla lurjus.
Allikas: opennet.ru
