Traducerea reflecțiilor lui Theodore Ts’o, creatorul sistemului de fișiere Ext4, despre dezvoltarea ext4, sistemul de fișiere BcacheFS, nucleul Linux, ZFS, codul de conduită și sistemele de fișiere în general:
Despre dezvoltarea ext4.
Fiecare versiune a nucleului ext4 beneficiază de contribuția a peste o duzină de persoane. În prezent, cea mai mare parte a timpului meu este dedicată revizuirii codului, efectuării de teste și îmbunătățirii aplicației de testare {kvm,gce,qemu,android}-xfstests. Și mă bazez foarte mult pe 2-3 alți dezvoltatori care lucrează la SUSE și IBM, care mă ajută cu revizuirea codului.
Despre BcacheFS
Sincer, bcachefs nu este un proiect complet singular — de exemplu, Kent a fost autorul a 72% din patch-urile dintre versiunile nucleului 6.11 și 6.12, în timp ce din 103 patch-uri pentru ext4 în aceeași perioadă, eu am fost autorul exact a 0%. Acest lucru se datorează faptului că eu cred ferm că programarea este un sport de echipă, iar misiunea mea ca lider tehnic este să permit participanților la ext4 să facă tot posibilul pentru a îmbunătăți sistemul de fișiere. Organizăm conferințe săptămânale, iar Derrick Wong, dezvoltator senior XFS și fost întreținător al XFS, participă la aceste conferințe — și, după cum se știe, l-am ajutat cu chestiuni legate de testarea XFS, iar Derrick m-a ajutat cu diferite chestiuni de testare pentru ext4 și a analizat chiar câteva patch-uri pentru ext4. Colaborăm unii cu alții, și este bine.
Permitem altor oameni să decidă dacă doresc să încredințeze datele lor cuiva care este un programator solitar, care ar putea fi mai talentat decât mine, dar vă voi da un indiciu — puteți «trișa», implicând o echipă în rezolvarea problemei. Nu este neapărat necesar să o faceți singur. Desigur, pentru asta trebuie să știți cum să treziți ce este mai bun în alții și trebuie să colaborați. Și o atitudine politicoasă unii față de alții în listele de discuții nu strică.
Despre nucleu, CoC, capacități și viitorul ext4
Ext4 realmente primește unele caracteristici noi, dar acestea sunt cele pe care companiile sunt dispuse să le finanțeze, deoarece rentabilitatea investiției pentru dezvoltarea funcției are sens în termeni de costuri și beneficii. De exemplu, fscrypt și directoarele fără distincție între litere majuscule și minuscule au fost funcții utile pentru Android și Chrome OS și au fost finanțate, cel puțin parțial, de aceste grupuri de dezvoltatori (Steam s-a preocupat de problema distincției între litere și a susținut unul dintre ingineri). Vrem să adăugăm suport pentru scrierea fără întreruperi (untorn), deoarece acest lucru va îmbunătăți performanța bazelor de date pe dispozitivele de stocare în bloc emulabile în cloud, unde pot fi garantate 16k de înregistrări atomice, ceea ce va elimina necesitatea dublării tamponării în MySQL și PostgreSQL.
(De fapt, Amazon și Google pot face asta în propriile produse de baze de date, făcând presupuneri despre modul în care funcționează Amazon EBS și Google Persistent Disk, dar vrem să facem acest lucru într-un mod mai general, care va fi mai sustenabil pe termen lung). Acesta este mai puțin atractiv decât lucruri precum reflinks, dar rentabilitatea investiției este mult mai ușor de justificat, atât din punct de vedere al costurilor (mai puțin efort de dezvoltare, testare și calificare pentru desfășurarea corporate), cât și pentru că beneficiile sunt mult mai ușor de cuantificat. Lucruri precum „pot economisi costul salariilor a XX ingineri programatori timp de cinci ani” sunt mult mai ușor de realizat pentru acest tip de funcții de creștere a performanței.
Spre deosebire de aceasta, reflinks este distractiv, dar nu am reușit să găsesc un client dispus să plătească costurile de dezvoltare, sau o companie care consideră că clienții lor vor cumpăra mai mult din produsul lor dacă adaugă reflinks în ext4. Poate părea oribil de corporatist, dar există o poveste despre cum inginerii ZFS au început un proiect de la zero, fără a cere permisiunea conducerii și fără a primi sugestii din partea departamentului de vânzări, și au prezentat Sun ceea ce era, de fapt, un fapt împlinit.
Sun părea să aibă succes, dar, dacă ne amintim că, în cele din urmă, a început să piardă bani și a fost nevoită să se vândă unei alte companii, iar organizația de inginerie care susținea ZFS nu mai există. Aproape în același timp cu anunțul ZFS, eu am participat la o cercetare în întreaga companie pentru a determina dacă are sens să investim în funcții de sistem de fișiere pentru AIX și Linux — și am concluzionat că nu, rentabilitatea investiției era mică, iar noile funcții de sistem de fișiere nu vor atrage un număr mai mare de clienți care să cumpere hardware, software sau sisteme IBM. Poate IBM a avut vremuri dificile, dar încă există, în timp ce Sun nu mai există.
Aproape în aceeași perioadă, reprezentanți ai mai multor companii Linux s-au adunat pentru a discuta cum va concura Linux cu ZFS. În cadrul acestei întâlniri s-a propus că btrfs va fi răspunsul pe termen lung, iar ext4 va fi soluția pe termen scurt, care va oferi suport pentru caracteristici precum redimensionarea în timp real, numere de blocuri de 64 de biți și alte funcții care erau disponibile în sistemele de operare tradiționale Legacy Unix, dar care lipseau în ext3.
La acea întâlnire, am fost rugat să definesc ce ar fi necesar pentru a crea un sistem de fișiere complet nou. Am efectuat o cercetare, analizând cât de mult efort a fost necesar pentru a crea sisteme de fișiere precum GPFS și JFS de la IBM, advfs de la Digital, și am estimat cât de mult a durat Sun pentru a crea ZFS și a aduce acest sistem de fișiere la starea complet gata pentru producție. Răspunsul pe care l-am primit a fost că ar fi nevoie de aproximativ 100 de ani om, cu o estimare inferioară de 50 de ani om și una superioară de 200 de ani om (dar aceasta a fost pentru GPFS, care era un sistem de fișiere de tip cluster, și prin urmare mult mai complex).
Am raportat asta la întâlnire, iar un inginer senior de la Intel a spus: „Nu, nu le spuneți șefilor, pentru că ei nu vor aproba niciodată proiectul! Spuneți-le că btrfs va fi gata în 18 luni”. Îi las pe oameni să decidă singuri când btrfs va atinge statutul de „gata pentru utilizare în mediul corporate”, în special pentru acele noi funcții avansate atractive care ar trebui să concureze cu ZFS, dar nu cred că este discutabil faptul că aceasta nu s-a întâmplat în 18 luni.
Şi chiar înainte ca Sun să se descompună, multe companii, care și-au trimis reprezentanții la întâlnire, au refuzat să participe inginerii la lucrul asupra btrfs, și acest lucru, desigur, nu a ajutat. Dar, probabil, acest lucru a fost legat de faptul că firmele sunt organizații raționale care iau propriile decizii despre rentabilitatea investițiilor, iar finanțarea unui nou sistem de fișiere nu avea același sens ca a spune oamenilor că Linux va avea un răspuns la ZFS.
Privind înapoi, se poate spune că, deși ZFS avea aceste funcții cu adevărat interesante, acestea nu au fost suficiente pentru a convinge majoritatea utilizatorilor să aleagă Solaris în detrimentul achiziționării unor platforme x86 mult mai ieftine și instalării Linux. Și când Sun a decis să încerce strategia OpenSolaris și Solaris x86, era deja prea târziu. Efectele de rețea erau enorme, iar strategia x86 nu oferea un răspuns la întrebarea cum a putut o singură companie, Sun, să plătească salariile tuturor inginerilor supertalentați care lucrau la Solaris. Achiziția unui server x86 de 5000 de dolari nu aduce o rentabilitate mare a vânzărilor comparativ cu serverul SunFire E10k Sparc de 100000 de dolari, pe care Sun o numea „punctul” din „dot Com”.
Ideea este că activitatea inginerilor în lumea reală este un compromis, iar realitățile de afaceri fac parte din acest compromis. Nu mă scuzați că prefer să mănânc și că vreau să câștig suficienți bani pentru a ieși la pensie într-o bună zi. Iar acest lucru, la rândul său, înseamnă că trebuie să înțeleg bine cum aduc valoare angajatorului, de cel puțin 10 ori mai mult decât salariul meu. Dacă pot face asta, continuând să lucrez cu software-ul open-source și ajutând alte companii să câștige bani, astfel încât să fie dispuse să contribuie la ext4, ei bine, aceasta este parte din provocare și de ce îmi place să lucrez cu software-ul open-source.
Și, revenind la Codul de conduită, voi spune că aproape toți întreținătorii principalelor sisteme de fișiere au susținut Codul nu din motive slabe liberale. Este pentru că avem nevoie de fiecare inginer dispus să contribuie la proiectul nostru, iar majoritatea dintre noi au văzut oameni care au refuzat să lucreze în Linux și au migrat către alte sisteme de operare (cunosc o persoană care a trecut pe Windows și care era un dezvoltator valoros al nucleului Linux la IBM Linux Technology Center) sau au lucrat la proiecte interne, dar nu la cele care necesitau interacțiune cu LKML, din cauza mediului toxic al câtorva persoane de pe lista de discuții.
În unele cazuri, temerile au fost nejustificate; de exemplu, Linus a țipat la un dezvoltator senior care ar fi trebuit să știe mai bine și cu care de cele mai multe ori Linus s-a întâlnit personal, având deja o relație stabilită. Problema este că nou-veniții nu știau acest lucru și se temeau — „ce se va întâmpla dacă Linus mă umilește în public la fel cum a procedat cu Steve”, fără să înțeleagă că în practică acest lucru nu se va întâmpla. De aceea avem CoC; nu este pentru noi, inginerii seniori, ci pentru a sprijini inginerii mai tineri din echipele noastre, pe care vrem să-i învățăm să ne înlocuiască în momentul în care va veni timpul să ne pensionăm, sau dacă ne va lovi un autobuz, sau în alte moduri în care vom părăsi această lume muritoare.
Nu uitați de 50-100 de ani de muncă pentru a crea un sistem de fișiere gata să fie utilizat în medii corporative. Avem nevoie de toți inginerii pe care îi putem atrage, iar mulți dintre noi fac muncă suplimentară în timpul liber, pentru că ne pasă. Crearea unui sistem de fișiere de înaltă calitate este un efort de echipă, și avem nevoie de fiecare inginer talentat pe care putem să-l obținem. Chiar dacă un inginer este un super programator 10x, dacă în cele din urmă va alunga o mulțime de alți ingineri care ar putea lucra la testare, optimizarea performanței etc., pur și simplu nu merită să-i permitem cuiva să fie un nemernic.
Sursa: opennet.ro
