Traduzione delle riflessioni di Theodore Ts’o, creatore del file system Ext4, sullo sviluppo di ext4, il file system BcacheFS, il kernel Linux, ZFS, il codice di condotta e i file system in generale:
Sullo sviluppo di ext4.
In ciascuna versione del kernel, a ext4 contribuiscono più di una mezza dozzina di persone. Attualmente, gran parte del mio tempo viene dedicata alla revisione del codice, alla conduzione di test e al miglioramento dell'applicazione di test {kvm,gce,qemu,android}-xfstests. E mi affido molto a 2-3 altri sviluppatori che lavorano in SUSE e IBM, che mi aiutano con la revisione del codice.
Su BcacheFS
A dire il vero, bcachefs non è un progetto completamente isolato — per esempio, Kent è stato l'autore del 72% delle patch tra le versioni del kernel 6.11 e 6.12, mentre su 103 patch a ext4 nello stesso periodo, io sono stato l'autore esatto di 0%. Questo perché sono fermamente convinto che la programmazione sia uno sport di squadra, e il mio lavoro come responsabile tecnico è quello di dare la possibilità ai membri di ext4 di fare del loro meglio per migliorare il file system. Organizzano conferenze settimanali, e Derrick Wong, sviluppatore senior di XFS e ex manutentore di XFS, partecipa a queste conferenze — e io, come noto, l'ho aiutato in questioni di test su XFS, mentre Derrick mi ha aiutato in varie questioni di test su ext4 e ha persino esaminato un paio di patch di ext4. Collaboriamo a vicenda, ed è un buon segno.
Lascio agli altri decidere se vogliono affidare i propri dati a qualcuno che è un solitario programmatore talentuoso, ma vi darò un suggerimento — potete "barare" coinvolgendo un team nella risoluzione del problema. Non è necessario farlo da soli. Certo, per questo è necessario sapere come far emergere il meglio negli altri, e bisogna lavorare insieme. E un atteggiamento cortese l'uno verso l'altro nelle mailing list non guasta.
Sul kernel, CoC, le funzionalità e il futuro di ext4
Ext4 davvero riceve alcune nuove funzionalità, ma sono quelle che le aziende sono pronte a finanziare, poiché il ritorno sull'investimento per lo sviluppo delle funzionalità ha senso in termini di costi e benefici. Ad esempio, fscrypt e le directory senza distinzione tra maiuscole e minuscole sono state funzionalità utili per Android e Chrome OS, e sono state finanziate, almeno in parte, da questi gruppi di sviluppatori (Steam era anche preoccupato per la distinzione tra maiuscole e minuscole e ha supportato uno degli ingegneri). Vogliamo aggiungere il supporto per le scritture ininterrotte (untorn), poiché ciò migliorerà le prestazioni delle basi dati su dispositivi di archiviazione emulati in cloud, dove è possibile garantire scritture atomiche di 16k, il che consente di eliminare il doppio buffering in MySQL e PostgreSQL.
(In realtà Amazon e Google possono farlo nei loro stessi prodotti DB, facendo ipotesi su come funzionano Amazon EBS e Google Persistent Disk, ma vogliamo farlo in modo più generale, che sarà più sostenibile a lungo termine). È meno attraente rispetto a cose come reflinks, ma il ritorno sugli investimenti è molto più facile da giustificare, sia perché i costi sono inferiori (meno lavoro per lo sviluppo, test e qualificazione per il dispiegamento aziendale), sia perché i benefici sono molto più facili da quantificare. Cose come 'posso risparmiare il costo dello stipendio di XX ingegneri programmatori per cinque anni' sono molto più facili da sostenere per questo tipo di funzionalità di miglioramento delle prestazioni.
Al contrario, i reflinks sono divertenti, ma non sono riuscito a trovare un cliente disposto a coprire i costi di sviluppo, né un'azienda che creda che i propri clienti acquisteranno di più il loro prodotto se aggiungono i reflinks in ext4. Può sembrare terribilmente aziendale, ma c'è una storia su come gli ingegneri ZFS hanno avviato un progetto da zero, senza chiedere il permesso alla direzione e senza ricevere suggerimenti dal reparto vendite, presentando a Sun ciò che era di fatto un dato di fatto.
Suona bene, ma se si pensa che alla fine Sun ha cominciato a perdere soldi, fino a dover vendere a un'altra società, e che in effetti l'organizzazione ingegneristica che supporta ZFS non esiste più. Circa in quel periodo, quando ZFS è stato annunciato, ho partecipato a uno studio dell'intera azienda per determinare se avesse senso investire in funzionalità di file system per AIX e Linux — e abbiamo concluso di no, il ritorno sugli investimenti era scarso e le nuove funzionalità del file system non avrebbero portato a un aumento di clienti che acquistano hardware, software o sistemi IBM. Forse per IBM sono arrivati tempi difficili, ma esiste ancora, mentre Sun no.
Circa nello stesso periodo, rappresentanti di diverse aziende Linux si sono riuniti per discutere come Linux potesse competere con ZFS. È stata durante questo incontro che è emersa l'idea che btrfs sarebbe stata la risposta a lungo termine, mentre ext4 sarebbe stata una soluzione a breve termine, in grado di supportare cose come il ridimensionamento in tempo reale, numeri di blocco a 64 bit e altre caratteristiche che erano presenti nei tradizionali sistemi operativi Unix-Legacy e che mancavano in ext3.
Durante quell'incontro, mi è stato chiesto di definire cosa fosse necessario per creare un file system completamente nuovo. Ho condotto una ricerca, osservando quanto lavoro fosse stato necessario per realizzare file system come GPFS e JFS di IBM, advfs di Digital, ho valutato quanto tempo aveva richiesto a Sun per creare ZFS e portare quel file system a uno stato completamente pronto per la produzione. La risposta che ho ottenuto è stata di circa 100 anni/uomo, con una stima bassa di 50 anni/uomo e una alta di 200 anni/uomo (ma questo si riferiva a GPFS, che era un file system cluster, quindi molto più complesso).
Ho riportato questo in riunione, e un ingegnere senior di Intel ha detto: «No, non dirlo ai dirigenti, perché non approveranno mai il progetto! Dì loro che btrfs sarà pronto in 18 mesi». Lascio alle persone decidere quando btrfs raggiungerà lo stato di «pronto per l'utilizzo aziendale», specialmente per quelle nuove e interessanti funzionalità avanzate che avrebbero dovuto competere con ZFS, ma non penso sia discutibile che ciò non è accaduto in 18 mesi.
E anche prima che Sun si sciogliesse, molte aziende che avevano inviato i loro rappresentanti all'incontro avevano rinunciato a coinvolgere ingegneri nel lavoro su btrfs, e questo, ovviamente, non ha aiutato. Ma probabilmente ciò era legato al fatto che le aziende sono organizzazioni razionali, che prendono decisioni autonome sulla redditività degli investimenti, e il finanziamento di un nuovo file system non aveva lo stesso senso di comunicare che Linux avrebbe avuto una risposta a ZFS.
Guardando indietro, si può dire che, sebbene ZFS avesse queste funzioni davvero interessanti, non erano sufficienti per convincere la maggior parte degli utenti a scegliere Solaris rispetto all'acquisto di piattaforme x86 molto più economiche e all'installazione di Linux. E quando Sun ha deciso di provare la strategia OpenSolaris e Solaris x86, era troppo tardi. Gli effetti di rete erano enormi, e la strategia x86 non offriva una risposta su come un'azienda, Sun, potesse pagare gli stipendi a tutti gli ingegneri super talentuosi che lavoravano su Solaris. Acquistare un server x86 da 5000 dollari non offre una grande redditività rispetto a server SunFire E10k Sparc da 100000 dollari, che Sun chiamava 'punto' nel 'dot Com'.
La verità è che l'attività ingegneristica nel mondo reale è un compromesso, e le realtà aziendali fanno parte di questo compromesso. Non mi scuso per il fatto che preferisco mangiare e che desidero guadagnare abbastanza denaro per andare in pensione un giorno. Questo, a sua volta, significa che devo capire bene come porto valore al mio datore di lavoro, almeno nella misura di dieci volte superiore al mio stipendio. Se posso farlo continuando a lavorare con il codice aperto e aiutando altre aziende a guadagnare denaro affinché siano disposte a contribuire a ext4, beh, questa è una parte della sfida e il motivo per cui amo lavorare con il codice aperto.
E, tornando al Codice di Comportamento, dirò che quasi tutti i maintainer dei principali file system hanno supportato il Codice non per vaghe considerazioni liberali. È perché abbiamo bisogno di ogni ingegnere disposto a contribuire al nostro progetto, e la maggior parte di noi ha visto persone rifiutare di lavorare su Linux e passare ad altri sistemi operativi (conosco una persona che è passata a Windows ed era un prezioso sviluppatore del kernel Linux presso l'IBM Linux Technology Center), oppure lavorare su progetti interni, ma non su quelli che richiedevano interazione con LKML, a causa dell'ambiente tossico di alcune persone nella mailing list.
In alcuni casi, le preoccupazioni erano infondate; per esempio, Linus ha urlato a un senior developer che davvero avrebbe dovuto sapere meglio e che, nella maggior parte dei casi, Linus incontrava di persona e avevano già un rapporto consolidato. Il problema è che i neofiti non sapevano questo e si spaventavano — 'e se Linus mi umilia in pubblico come ha fatto con Steve', senza rendersi conto che in pratica non accadrà. Ecco perché abbiamo il CoC; non è per noi ingegneri più esperti, ma per supportare gli ingegneri più giovani nei nostri team, che vogliamo formare affinché ci sostituiscano in un momento successivo, quando sarà il momento di andare in pensione, o se ci investe un autobus, o in altro modo lasciamo questo mondo mortale.
Non dimentichiamo i 50-100 uomini-anno di lavoro per creare un file system pronto per essere utilizzato in un ambiente aziendale. Abbiamo bisogno di tutti gli ingegneri che possiamo reclutare, e molti di noi svolgono lavoro extra nel loro tempo libero, perché ci interessa. Creare un file system di alta qualità è un lavoro di squadra, e abbiamo bisogno di ogni ingegnere talentuoso che possiamo ottenere. Anche se un ingegnere è un super programmatore 10x, se in definitiva spaventa un sacco di altri ingegneri che potrebbero lavorare su test, ottimizzazione delle prestazioni, ecc., semplicemente non vale la pena permettere a qualcuno di essere un bastardo.
Fonte: opennet.ru
