Traduzione dei pensieri di Theodore Ts'o, creatore del file system Ext4, sullo sviluppo di ext4, del file system BcacheFS e del kernel. Linux, ZFS, il codice di condotta e i file system in generale:
Informazioni sullo sviluppo di ext4.
Più di una mezza dozzina di persone contribuiscono a ogni rilascio del kernel ext4. Attualmente, la maggior parte del mio tempo è dedicata alla revisione del codice, all'esecuzione dei test e al miglioramento dell'applicazione di test.kvm,gce,qemu,android}-xfstests. E mi affido molto ad altri due o tre sviluppatori che lavorano presso SUSE e IBM che mi aiutano con le revisioni del codice.
Informazioni su BcacheFS
Per essere onesti, bcachefs non è un progetto completamente solista: ad esempio, Kent è stato l'autore del 72% delle patch tra le versioni del kernel 6.11 e 6.12, mentre delle 103 patch ext4 durante lo stesso periodo di tempo, sono stato l'autore esattamente dello 0%. Questo perché credo fermamente che la programmazione sia uno sport di squadra e il mio lavoro come responsabile tecnico è consentire ai membri di ext4 di fare del loro meglio per migliorare il file system. Abbiamo conferenze settimanali e Darrick Wong, uno sviluppatore senior di XFS ed ex manutentore di XFS, partecipa a queste conferenze - e sono noto per aiutarlo con i problemi di test di XFS, e Darrick mi ha aiutato con vari problemi di test di ext4 e ha anche revisionato un paio di patch est4. Collaboriamo tra loro e questo è positivo.
Lascerò che siano gli altri a decidere se vogliono affidare i propri dati a qualcuno che è un programmatore solitario e che potrebbe benissimo essere più talentuoso di me, ma ti darò un suggerimento: puoi "imbrogliare" trovare una squadra per risolvere il problema. Non devi farlo da solo. Naturalmente, per fare questo, è necessario saper tirare fuori il meglio dagli altri e lavorare insieme. Ed essere educati gli uni con gli altri nelle mailing list non fa male.
Informazioni su kernel, CoC, funzionalità e futuro di ext4
Ext4 ottiene alcune nuove funzionalità, ma queste sono quelle che le aziende sono disposte a finanziare perché il ROI dello sviluppo della funzionalità ha senso da una prospettiva costi-benefici. Ad esempio, fscrypt e le directory case-insensitive erano funzionalità utili per Android e Chrome OS, e sono stati finanziati, almeno in parte, da questi team di sviluppo (anche Steam era preoccupata per la gestione dei casi e ha supportato uno degli ingegneri). Vogliamo aggiungere il supporto per le scritture non modificate perché migliorerà le prestazioni del database sui dispositivi a blocchi emulati basati su cloud, dove è possibile garantire scritture atomiche a 16k, eliminando il double buffering in MySQL e PostgreSQL.
(In realtà Amazon e Google potrebbero farlo nei propri prodotti DBMS facendo ipotesi su come funzionano Amazon EBS e Google Persistent Disk, ma noi vogliamo farlo in un modo più generale che sarà più gestibile a lungo termine). È meno attraente di cose come i reflink, ma il ROI è molto più facile da giustificare, sia perché i costi sono inferiori (meno lavoro di sviluppo, test e qualificazione per le implementazioni aziendali) sia perché i vantaggi sono molto più facili da quantificare. Cose come "Posso risparmiare il costo di XX stipendi di ingegneri software a tempo pieno in cinque anni" sono molto più facili da fare per questo tipo di funzionalità di produttività.
Al contrario, i reflink sono divertenti, ma non sono riuscito a trovare un cliente disposto a pagare i costi di sviluppo o un'azienda che crede che i propri clienti acquisteranno una maggiore quantità del loro prodotto se aggiungono reflink a ext4. Ciò può sembrare terribilmente aziendale, ma c'è una storia su come gli ingegneri ZFS hanno avviato un progetto da zero, senza chiedere il permesso al management o ottenere input dalle vendite, e hanno presentato a Sun quello che era effettivamente un fatto compiuto.
Sembra fantastico, ma ricorda che Sun finì per perdere soldi finché non fu costretta a vendersi a un'altra azienda, e l'organizzazione di ingegneria che supportava ZFS non esiste più. Intorno al periodo in cui ZFS fu annunciato, fui coinvolto in uno studio a livello aziendale per determinare se avesse senso investire in funzionalità del file system per AIX e Linux — e siamo giunti alla conclusione che no, il ritorno sull'investimento è esiguo e le nuove funzionalità del file system non porteranno più clienti ad acquistare hardware, software o sistemi IBM. IBM potrebbe attraversare un periodo difficile, ma è ancora in attività, mentre Sun no.
Nello stesso periodo, i rappresentanti di diversi Linux-le aziende si sono riunite per capire come Linux competerà con ZFS. Fu in questa riunione che venne avanzata l'idea che btrfs sarebbe stata la soluzione a lungo termine, mentre ext4 sarebbe stata la soluzione a breve termine, fornendo supporto per funzionalità come il ridimensionamento a caldo, i numeri di blocco a 64 bit e altre caratteristiche presenti nei sistemi operativi Unix tradizionali che ext3 non possedeva.
In quell'incontro mi fu chiesto di determinare cosa sarebbe stato necessario per creare un file system completamente nuovo. Ho fatto qualche ricerca, osservando lo sforzo necessario per creare file system come GPFS e JFS di IBM, advfs di Digital, e ho stimato quanto ci è voluto a Sun per creare ZFS e portare quel file system in uno stato 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 stima alta di 200 anni-uomo (ma era per GPFS, che era un file system in cluster, e quindi molto più complesso).
Ne ho parlato in una riunione e un ingegnere senior della Intel ha detto: “No, non dirlo ai dirigenti perché non approveranno mai il progetto! Dite loro che btrfs sarà pronto tra 18 mesi." Lascerò che siano le persone a decidere quando btrfs raggiungerà lo status di "pronto per l'impresa", soprattutto per quelle nuove e sexy funzionalità avanzate che avrebbero dovuto competere con ZFS, ma non credo che sia in discussione il fatto che non siano 18 mesi da adesso.
Ancor prima che Sun si sciogliesse, molte delle aziende che inviarono rappresentanti all'incontro si rifiutarono di far partecipare i propri ingegneri a btrfs, il che, ovviamente, non aiutò. Ma questo probabilmente perché le aziende sono organizzazioni razionali che prendono le proprie decisioni sul ritorno sull'investimento, e finanziare un nuovo file system non aveva tanto senso quanto dire alla gente cosa Linux Ci sarà una risposta a ZFS.
A posteriori, sebbene ZFS avesse queste caratteristiche davvero interessanti, non erano sufficienti a convincere la maggior parte degli utenti a scegliere Solaris invece di acquistare piattaforme x86 molto più economiche e installarle LinuxE 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'azienda, Sun, potesse pagare gli stipendi di tutti gli ingegneri di grande talento che lavoravano su Solaris. Acquistare un server x86 per 5000 dollari non fornisce un elevato ritorno sulle vendite rispetto a server La SunFire E10k Sparc da 100000 dollari, che Sun chiamava il "punto" di "dot.com".
Il punto è che l’ingegneria nel mondo reale è un compromesso e le realtà aziendali fanno parte di quel compromesso. Non mi scuso per il fatto che scelgo di mangiare cibo e che voglio guadagnare abbastanza soldi per andare in pensione un giorno. E questo, a sua volta, significa che devo avere una buona comprensione di come apportare valore al datore di lavoro almeno 10 volte il mio stipendio. Se riesco a farlo mentre lavoro ancora nell'open source e aiuto altre aziende a fare soldi in modo che siano disposte a contribuire a ext4, beh, questa è parte della sfida e il motivo per cui amo lavorare nell'open source.
E, tornando al Codice di condotta, dirò che quasi tutti i manutentori dei principali file system hanno supportato il Codice non per qualche debole considerazione liberale. È perché abbiamo bisogno di ogni ingegnere disposto a contribuire al nostro progetto, e la maggior parte di noi ha visto persone che si sono rifiutate di lavorare in Linux e sono passato ad altri sistemi operativi (conosco una persona che è passata a Windows ed è stato un prezioso sviluppatore di kernel Linux presso IBM Linux Centro Tecnologico) o ha lavorato a progetti interni, ma non a nulla che richiedesse interazione con LKML, a causa dell'ambiente tossico creato da diverse persone nella mailing list.
In alcuni casi i timori erano infondati; per esempio, Linus stava urlando contro uno sviluppatore senior che in realtà avrebbe dovuto conoscerlo meglio e che nella maggior parte dei casi Linus aveva incontrato di persona e avevano una relazione già consolidata. Il problema è che i nuovi arrivati non lo sapevano e avevano paura: "e se Linus mi umiliasse in pubblico nello stesso modo in cui ha fatto con Steve", senza rendersi conto che in pratica ciò non sarebbe accaduto. Ecco perché abbiamo CoC; questo non è per noi ingegneri senior, ma per supportare gli ingegneri più giovani dei nostri team che vogliamo formare per sostituirci ad un certo punto quando sarà il momento di andare in pensione, o se veniamo investiti da un autobus, o altrimenti lasceremo questo mondo mortale.
Non dimenticare i 50-100 anni-uomo di lavoro necessari per creare un file system pronto per l'uso in un ambiente aziendale. Abbiamo bisogno di tutti gli ingegneri possibili e molti di noi svolgono un lavoro extra nel tempo libero perché ci tengono. Costruire un file system di alta qualità è un lavoro di squadra e abbiamo bisogno di ogni ingegnere di talento possibile. Anche se un ingegnere è un super programmatore 10x, se finisce per spaventare un gruppo di altri ingegneri che potrebbero lavorare su test, messa a punto delle prestazioni, ecc., non vale la pena lasciare che qualcuno sia uno stronzo.
Fonte: opennet.ru
