Riflessioni di Theodore Ts’o, creatore del filesystem Ext4, sulla sviluppo di ext4, il filesystem BcacheFS, il kernel Linux, ZFS, il codice etico e i filesystem in generale:
Sullo sviluppo di ext4.
Ogni rilascio del kernel ext4 coinvolge più di una mezza dozzina di persone. Attualmente, gran parte del mio tempo è dedicato alla revisione del codice, esecuzione di test e 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 assistono nella revisione del codice.
Su BcacheFS
A dire il vero, bcachefs non è un progetto completamente isolato: ad esempio, Kent è stato l'autore del 72% delle patch tra le versioni del kernel 6.11 e 6.12, mentre tra le 103 patch a ext4 nello stesso periodo, io non ho scritto nemmeno l'1%. Questo perché sono fermamente convinto che la programmazione sia uno sport di squadra, e il mio compito come tecnico leader è dare la possibilità ai partecipanti di ext4 di fare del loro meglio per migliorare il file system. Organizziamo conferenze settimanali, e Derrick Wong, senior developer di XFS e precedente maintainer di XFS, partecipa a queste conferenze—e io, come è noto, l'ho aiutato con questioni relative al testing di XFS, mentre Derrick mi ha assistito con varie questioni di testing di ext4 e ha persino esaminato un paio di patch di ext4. Collaboriamo e questo è positivo.
Lascio agli altri decidere se vogliono fidarsi dei loro dati a qualcuno che è un brillante programmatore solitario, il quale potrebbe anche essere più talentuoso di me, ma ti darò un suggerimento: puoi "barare" coinvolgendo un team nella risoluzione del problema. Non è necessario farlo da soli. Certamente, per questo è necessario sapere come risvegliare il meglio negli altri e lavorare insieme. Inoltre, è utile mantenere un atteggiamento cortese nei forum di discussione.
Sul kernel, CoC, funzionalità e futuro di ext4
Ext4 sta effettivamente ricevendo alcune nuove funzionalità, ma queste sono quelle che le aziende sono disposte a finanziare, poiché il ritorno degli investimenti nello sviluppo delle funzionalità ha senso in termini di costi e benefici. Ad esempio, fscrypt e le directory senza distinzione tra maiuscole e minuscole erano 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 gestione delle maiuscole e ha supportato uno degli ingegneri). Vogliamo aggiungere il supporto per la scrittura senza interruzioni (untorn), poiché questo migliorerà le prestazioni dei database su dispositivi di archiviazione a blocchi emulati nel cloud, dove è possibile garantire 16k di scritture atomiche, eliminando così la doppia memorizzazione temporanea in MySQL e PostgreSQL.
(In realtà, Amazon e Google possono farlo nei loro prodotti SGBD, 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). Questo è meno attraente rispetto a cose come i reflink, 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 l'implementazione aziendale), sia perché i vantaggi sono molto più facili da quantificare. Cose come 'posso risparmiare il costo dello stipendio di XX ingegneri programmatori a tempo pieno per cinque anni' sono molto più facili da fare per questo tipo di funzionalità di aumento delle prestazioni.
A differenza di questo, 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ù del loro prodotto se aggiungono reflinks in ext4. Può sembrare terribilmente aziendale, ma c'è una storia su come gli ingegneri ZFS abbiano 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 già un fatto compiuto.
Sembra interessante, ma se consideriamo che alla fine Sun ha iniziato a perdere soldi, fino a dover vendere l'azienda a un'altra società, e che di fatto l'organizzazione ingegneristica che supportava ZFS non esiste più. Circa nello stesso periodo in cui ZFS è stato annunciato, ho partecipato a una ricerca dell'intera azienda per capire se valesse la pena investire in funzionalità di file system per AIX e Linux — e siamo giunti alla conclusione che non ne valesse la pena, il ritorno sugli investimenti era esiguo, e nuove funzionalità del file system non avrebbero aumentato il numero di clienti che acquistano hardware, software o sistemi IBM. Forse IBM ha attraversato momenti difficili, ma è ancora in vita, mentre Sun non lo è più.
Circa nello stesso periodo, i rappresentanti di diverse aziende Linux si sono riuniti per discutere di come Linux potesse competere con ZFS. È stata proprio in quella riunione che è emersa l'idea che btrfs sarebbe stata la risposta a lungo termine, mentre ext4 avrebbe fornito una soluzione a breve termine, supportando funzionalità 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 determinare cosa sarebbe necessario per creare un filesystem completamente nuovo. Ho condotto una ricerca, esaminando quanti sforzi sono stati necessari per realizzare filesystem come GPFS e JFS di IBM, advfs di Digital, e valutato quanto tempo ci sia voluto a Sun per sviluppare ZFS e portarlo a uno stato completamente pronto per la produzione. La risposta che ho ricevuto è stata di circa 100 anni-uomo, con una stima bassa di 50 anni-uomo e una alta di 200 anni-uomo (ma questo era per GPFS, che era un filesystem a cluster e quindi molto più complesso).
Ne ho parlato in riunione, e un anziano ingegnere di Intel ha detto: «No, non parlargliene ai dirigenti, perché non approveranno mai il progetto! Dì loro che btrfs sarà pronto tra 18 mesi». Lascio che siano le persone a decidere quando btrfs raggiungerà lo stato di «pronto per l'uso aziendale», specialmente per quelle nuove e interessanti funzionalità avanzate che dovrebbero competere con ZFS, ma non penso sia oggetto di discussione il fatto che ciò non sia avvenuto entro 18 mesi.
E anche prima che Sun si separasse, molte aziende che avevano inviato i loro rappresentanti alla riunione rifiutarono di coinvolgere gli ingegneri nel lavoro su btrfs, e ciò certamente non aiutò. Ma probabilmente ciò era dovuto al fatto che le aziende sono organizzazioni razionali che prendono decisioni autonome in merito al ritorno sugli investimenti, e finanziare un nuovo filesystem non aveva lo stesso senso che comunicare alle persone che Linux avrebbe avuto una risposta a ZFS.
Guardando indietro, si può dire che, sebbene ZFS avesse davvero funzioni interessanti, queste 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 decise di provare la strategia OpenSolaris e Solaris x86, era troppo tardi. Gli effetti di rete erano enormi e la strategia x86 non rispondeva alla domanda su come un'unica azienda, Sun, potesse pagare gli stipendi a tutti i talentuosi ingegneri che avevano lavorato su Solaris. Acquistare un server x86 per 5000 dollari non offre un grande ritorno rispetto a server SunFire E10k Sparc a 100000 dollari, che Sun definiva "il punto" nel "dot Com".
La realtà è che l'ingegneria nel mondo reale è un compromesso, e le realtà aziendali fanno parte di questo compromesso. Non mi scuso per il fatto di preferire mangiare bene e di voler guadagnare abbastanza denaro da poter andare in pensione un giorno. Questo, a sua volta, significa che devo capire bene come fornisco valore al mio datore di lavoro, almeno dieci volte superiore al mio stipendio. Se posso farlo, continuando a lavorare con il software open source e aiutando altre aziende a guadagnare in modo che siano pronte a contribuire a ext4, beh, questa è parte della sfida ed è per questo che amo lavorare con l'open source.
E, tornando al Codice di condotta, dirò che quasi tutti i maintainer dei principali file system hanno supportato il Codice non per qualche vago motivo liberale. È perché abbiamo bisogno di ogni ingegnere disposto a contribuire al nostro progetto, e la maggior parte di noi ha visto persone rifiutarsi 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) o lavorare su progetti interni, ma non su quelli che richiedevano interazioni con la LKML, a causa dell'ambiente tossico di alcune persone nella mailing list.
In alcune situazioni, le preoccupazioni si sono rivelate infondate; ad esempio, Linus ha urlato a un senior developer che davvero doveva sapere meglio, con il quale Linus si era già incontrato di persona e aveva avuto relazioni consolidate. Il problema è che i nuovi arrivati non lo sapevano e si spaventavano: "E se Linus mi umilia in pubblico come ha fatto con Steve?", senza capire che nella pratica ciò non accade. Ecco perché abbiamo il CoC; non è per noi, ingegneri senior, ma per supportare i più giovani nei nostri team, che vogliamo formare per sostituirci quando verrà il momento di andare in pensione, oppure quando saremo investiti da un autobus, o lasciamo questo mondo mortale in altro modo.
Non dimenticate che ci vogliono da 50 a 100 anni-uomo per creare un file system pronto per l'uso in un ambiente aziendale. Abbiamo bisogno di tutti gli ingegneri che possiamo attrarre, e molti di noi fanno un lavoro extra nel tempo libero, perché ci importa. 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 dieci volte migliore, se alla fine spaventa molti altri ingegneri che potrebbero lavorare sui test, sull'ottimizzazione delle prestazioni, ecc., semplicemente non vale la pena permettere a qualcuno di essere scortese.
Fonte: opennet.ru
