Traduzione delle riflessioni di Theodore Ts'o, creatore del filesystem Ext4, sulla sviluppo di ext4, filesystem BcacheFS, kernel Linux, ZFS, codice di condotta e filesystem in generale: <\/p>\n
Sullo sviluppo di ext4<\/b>. <\/p>\n Ogni rilascio del kernel ext4 coinvolge pi\u00f9 di una mezza dozzina di persone. Attualmente, gran parte del mio tempo \u00e8 dedicato alla revisione del codice, esecuzione di test e miglioramento dell'applicazione di test {kvm<\/a>,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. <\/p><\/blockquote>\n Su BcacheFS<\/b> <\/p>\n A dire il vero, bcachefs non \u00e8 un progetto del tutto solitario: per esempio, Kent ha creato il 72% delle patch tra le versioni del kernel 6.11 e 6.12, mentre dei 103 patch per ext4 nello stesso periodo, io non ne ho creato nemmeno uno. Questo perch\u00e9 sono fermamente convinto che la programmazione sia uno sport di squadra e il mio compito come leader tecnico \u00e8 di permettere ai partecipanti di ext4 di fare del loro meglio per migliorare il filesystem. Organizziamo conferenze settimanali, e Derrick Wong, senior developer di XFS ed ex manutentore di XFS, partecipa a queste conferenze \u2014 e io, notoriamente, l'ho aiutato con questioni riguardanti il testing di XFS, mentre Derrick mi ha assistito con vari aspetti del testing di ext4 e ha persino revisionato un paio di patch di ext4. Collaboriamo l'uno con l'altro, ed \u00e8 una cosa positiva. <\/p>\n Lascio ad altre persone decidere se desiderano affidare i propri dati a qualcuno che \u00e8 un programmista solitario, che potrebbe benissimo essere pi\u00f9 talentuoso di me, ma ti dar\u00f2 un suggerimento: puoi \"barare\" coinvolgendo un team nella risoluzione del problema. Non \u00e8 necessario farlo da soli. Certamente, per questo \u00e8 necessario sapere come risvegliare il meglio negli altri e bisogna lavorare insieme. E comportarsi in modo cortese gli uni con gli altri sulle mailing list non guasta. <\/p><\/blockquote>\n Sul kernel, CoC, funzionalit\u00e0 e futuro di ext4<\/b> <\/p>\n Ext4 sta effettivamente ricevendo alcune nuove funzionalit\u00e0, ma queste sono quelle che le aziende sono disposte a finanziare, poich\u00e9 il ritorno degli investimenti nello sviluppo delle funzionalit\u00e0 ha senso in termini di costi e benefici. Ad esempio, fscrypt e le directory senza distinzione tra maiuscole e minuscole erano funzionalit\u00e0 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\u00e9 questo migliorer\u00e0 le prestazioni dei database su dispositivi di archiviazione a blocchi emulati nel cloud, dove \u00e8 possibile garantire 16k di scritture atomiche, eliminando cos\u00ec la doppia memorizzazione temporanea in MySQL e PostgreSQL. <\/p>\n (Infatti, Amazon e Google possono farlo nei loro stessi prodotti di DBMS, facendo ipotesi su come funzionano Amazon EBS e Google Persistent Disk, ma vogliamo farlo in un modo pi\u00f9 generale, che sia sostenibile a lungo termine). Questo \u00e8 meno attraente di cose come i reflink, ma il ritorno sull'investimento \u00e8 molto pi\u00f9 facile da giustificare, sia perch\u00e9 i costi sono inferiori (meno lavoro di sviluppo, testing e qualificazione per il dispiegamento aziendale), sia perch\u00e9 i benefici sono molto pi\u00f9 facili da quantificare. Cose come \"posso risparmiare il costo dello stipendio di XX ingegneri programmatori nel giro di cinque anni\" sono molto pi\u00f9 facili da giustificare per questo tipo di funzioni di miglioramento delle prestazioni. <\/p>\n Al contrario, i reflink sono divertenti, ma non sono riuscito a trovare un cliente disposto a pagare le spese di sviluppo, o un'azienda che creda che i loro clienti acquisterebbero di pi\u00f9 il loro prodotto se aggiungessero i reflink in ext4. Questo pu\u00f2 sembrare terribilmente aziendale, ma c'\u00e8 una storia su come gli ingegneri di ZFS iniziarono un progetto da zero, senza chiedere il permesso alla direzione e senza ricevere suggerimenti dal reparto vendite, e presentarono a Sun quello che era praticamente un fatto compiuto. <\/p>\n Suona bene, ma se si considera che alla fine Sun ha iniziato a perdere denaro, fino a doversi vendere a un'altra azienda, e di fatto l'organizzazione ingegneristica che supportava ZFS non esiste pi\u00f9. Circa nello stesso periodo in cui ZFS \u00e8 stato annunciato, ho partecipato a una ricerca di tutta l'azienda per vedere se aveva senso investire in funzioni di filesystem per AIX e Linux \u2014 e siamo arrivati alla conclusione che no, il ritorno sull'investimento era scarso e le nuove funzioni di filesystem non avrebbero portato a un aumento dei clienti che acquistano hardware, software o sistemi IBM. Forse per IBM erano tempi difficili, ma esiste ancora, mentre Sun no. <\/p>\n Circa nello stesso periodo, rappresentanti di diverse aziende Linux si sono riuniti per pensare a come Linux potesse competere con ZFS. \u00c8 stato in questo incontro che \u00e8 emersa l'idea che btrfs sarebbe stata la risposta a lungo termine, mentre ext4 sarebbe stata una soluzione a breve termine che avrebbe garantito il supporto per cose come il ridimensionamento in tempo reale, numeri di blocco a 64 bit e altre cose che erano presenti nei tradizionali Legacy Unix OS e che mancavano in ext3. <\/p>\n Durante quell'incontro, mi \u00e8 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 \u00e8 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\u00f9 complesso). <\/p>\n Ne ho parlato durante una riunione, e un certo ingegnere senior di Intel ha detto: \"No, non dirlo ai dirigenti, perch\u00e9 non approveranno mai il progetto! D\u00ec loro che btrfs sar\u00e0 pronto in 18 mesi\". Lascio a tutti decidere quando btrfs raggiunger\u00e0 lo status di \"pronto per l'uso aziendale\", specialmente per quelle nuove e interessanti funzioni avanzate che dovevano competere con ZFS, ma non penso si possa discutere sul fatto che ci\u00f2 non sia avvenuto entro 18 mesi. <\/p>\n E anche prima che Sun si dissolvesse, molte aziende che avevano inviato i loro rappresentanti all'incontro rifiutarono di partecipare gli ingegneri ai lavori su btrfs, e questo, ovviamente, non aiut\u00f2. Probabilmente, era dovuto al fatto che le aziende sono organizzazioni razionali che prendono le proprie decisioni sul ritorno sugli investimenti, e finanziare un nuovo file system non aveva lo stesso senso di raccontare alla gente che Linux avrebbe avuto una risposta a ZFS. <\/p>\n Guardando indietro, si pu\u00f2 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\u00f9 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<\/a> SunFire E10k Sparc a 100000 dollari, che Sun chiamava \"punto\" nel \"dot Com\". <\/p>\n La verit\u00e0 \u00e8 che l'attivit\u00e0 ingegneristica nel mondo reale \u00e8 un compromesso, e le realt\u00e0 aziendali fanno parte di questo compromesso. Non mi scuso per preferire mangiare cibo, e per volere guadagnare abbastanza da poter andare in pensione un giorno. Questo, a sua volta, significa che devo capire bene come porto valore al mio datore di lavoro, almeno per dieci volte superiore al mio stipendio. Se posso farlo continuando a lavorare con codice aperto e aiutando altre aziende a guadagnare denaro affinch\u00e9 siano pronte a contribuire a ext4, beh, questa \u00e8 parte della sfida e il motivo per cui amo lavorare con codice aperto. <\/p>\n E, tornando al Codice di condotta, dir\u00f2 che quasi tutti i maintainer dei principali file system hanno supportato il Codice non per qualche vago motivo liberale. \u00c8 perch\u00e9 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 \u00e8 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. <\/p>\n In alcuni casi, le preoccupazioni erano infondate; per esempio, Linus url\u00f2 a un senior developer che davvero avrebbe dovuto sapere meglio e con cui Linus si incontrava di persona nella maggior parte dei casi, e avevano gi\u00e0 una relazione consolidata. Il problema \u00e8 che i nuovi arrivati non sapevano questo e avevano paura - \"e se Linus mi umilia in pubblico proprio come ha fatto con Steve\", senza capire che in pratica non accade. Ecco perch\u00e9 abbiamo il CoC; non \u00e8 per noi, ingegneri senior, ma per sostenere i pi\u00f9 giovani nei nostri team, ai quali vogliamo insegnare affinch\u00e9 possano, in un certo momento, sostituirci quando sar\u00e0 il momento di andare in pensione, o se un autobus ci investe, o in altro modo lasciamo questo mondo mortale. <\/p>\n Non dimenticate i 50-100 anni-uomo di lavoro dedicati a creare un file system pronto per l'uso in ambito aziendale. Abbiamo bisogno di tutti gli ingegneri che possiamo coinvolgere e molti di noi svolgono lavoro supplementare nel tempo libero, perch\u00e9 ci interessa. Creare un file system di alta qualit\u00e0 \u00e8 un lavoro di squadra e abbiamo bisogno di ogni ingegnere talentuoso che possiamo attirare. Anche se un ingegnere \u00e8 un super programmatore dieci volte, se alla fine 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 scontroso. <\/p><\/blockquote>\n\n
\n
\n