Traduzione delle riflessioni di Theodore Ts\u2019o, 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: <\/p>\n
Sullo sviluppo di ext4<\/b>. <\/p>\n In ciascuna versione del kernel, a ext4 contribuiscono pi\u00f9 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<\/a>,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. <\/p><\/blockquote>\n Su BcacheFS<\/b> <\/p>\n A dirla tutta, bcachefs non \u00e8 un progetto del tutto isolato: ad esempio, Kent ha scritto il 72% delle patch tra le versioni del kernel 6.11 e 6.12, mentre su 103 patch per ext4 nello stesso periodo, io ne ho scritte esattamente 0%. Questo perch\u00e9 credo fermamente che la programmazione sia uno sport di squadra, e il mio lavoro come leader tecnico consiste nel dare l'opportunit\u00e0 ai membri di ext4 di fare del loro meglio per migliorare il file system. Facciamo conferenze settimanali, e Derrick Wong, sviluppatore senior di XFS e ex maintainers di XFS, partecipa a queste conferenze: io, come \u00e8 noto, lo ho aiutato con i test di XFS, e Derrick mi ha assistito con diversi aspetti dei test di ext4 e ha persino esaminato un paio di patch di ext4. Collaboriamo tra di noi, ed \u00e8 positivo. <\/p>\n Lascio ad altre persone decidere se vogliono affidare i propri dati a un singolo programmatore talentuoso che potrebbe essere pi\u00f9 capace di me, ma vi do un suggerimento: si pu\u00f2 \"barare\" coinvolgendo un team nella risoluzione dei problemi. Non \u00e8 necessario farlo da soli. Certo, per questo \u00e8 necessario sapere come far emergere il meglio negli altri, e bisogna lavorare insieme. E un atteggiamento cortese tra di noi nelle mailing list non guasta. <\/p><\/blockquote>\n Sul kernel, CoC, le funzionalit\u00e0 e il futuro di ext4<\/b> <\/p>\n Ext4 davvero riceve alcune nuove funzionalit\u00e0, ma sono quelle che le aziende sono pronte a finanziare, poich\u00e9 il ritorno sull'investimento per lo sviluppo delle funzionalit\u00e0 ha senso in termini di costi e benefici. Ad esempio, fscrypt e le directory senza distinzione tra maiuscole e minuscole sono state 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 distinzione tra maiuscole e minuscole e ha supportato uno degli ingegneri). Vogliamo aggiungere il supporto per le scritture ininterrotte (untorn), poich\u00e9 ci\u00f2 migliorer\u00e0 le prestazioni delle basi dati su dispositivi di archiviazione emulati in cloud, dove \u00e8 possibile garantire scritture atomiche di 16k, il che consente di eliminare il doppio buffering in MySQL e PostgreSQL. <\/p>\n (In effetti, Amazon e Google possono fare questo nei propri prodotti DBMS facendo supposizioni su come funzionano Amazon EBS e Google Persistent Disk, ma noi vogliamo farlo in modo pi\u00f9 generale, il che sar\u00e0 pi\u00f9 sostenibile nel lungo termine). \u00c8 meno allettante di cose come reflinks, ma il ritorno sugli investimenti \u00e8 molto pi\u00f9 facile da giustificare, sia perch\u00e9 i costi sono pi\u00f9 bassi (meno lavoro di sviluppo, test e qualificazione per il deployment aziendale), sia perch\u00e9 i benefici sono molto pi\u00f9 facili da quantificare. \u00c8 pi\u00f9 semplice affermare cose come \"posso risparmiare il costo degli stipendi di XX ingegneri programmatori nel corso di cinque anni\" per questo tipo di funzionalit\u00e0 di aumento delle prestazioni. <\/p>\n A differenza di questo, i reflink sono divertenti, ma non sono riuscito a trovare un cliente disposto a coprire i costi di sviluppo, n\u00e9 un'azienda che ritenesse che i propri clienti acquisterebbero di pi\u00f9 se aggiungessero i reflink in ext4. Potrebbe sembrare terribilmente aziendale, ma c'\u00e8 una storia su come gli ingegneri di ZFS abbiano avviato un progetto da zero, senza chiedere il permesso alla dirigenza e senza ricevere suggerimenti dal reparto vendite, per presentare a Sun ci\u00f2 che era di fatto un dato di fatto. <\/p>\n Sembra fantastico, ma se si considera che alla fine Sun ha cominciato a perdere soldi, fino a dover vendere se stessa a un'altra azienda, e di fatto l'organizzazione ingegneristica che supporta ZFS non esiste pi\u00f9. Circa nello stesso periodo in cui \u00e8 stata annunciata ZFS, ho partecipato a uno studio aziendale su quanto avesse senso investire in funzionalit\u00e0 di file system per AIX e Linux \u2014 e siamo giunti alla conclusione che no, il ritorno su investimento era scarso e le nuove funzionalit\u00e0 di file system non avrebbero portato a un aumento del numero di clienti che acquistano hardware, software o sistemi IBM. Forse per IBM sono arrivati tempi difficili, ma esiste ancora, mentre Sun no. <\/p>\n Circa nello stesso periodo, i rappresentanti di alcune aziende Linux si sono riuniti per pensare a come Linux potesse competere con ZFS. \u00c8 stato proprio in questo incontro che \u00e8 stata avanzata l'idea che btrfs sarebbe stata la risposta a lungo termine, mentre ext4 sarebbe stata una soluzione a breve termine in grado di fornire supporto per cose come il ridimensionamento in tempo reale, numeri di blocco a 64 bit e altre funzioni che erano presenti nei tradizionali sistemi operativi Unix Legacy e che mancavano in ext3. <\/p>\n Durante quell'incontro, mi \u00e8 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 \u00e8 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\u00f9 complesso). <\/p>\n Ne ho parlato in una riunione e un certo ingegnere senior di Intel ha detto: \u00abNo, non dirlo ai dirigenti, perch\u00e9 non approveranno mai il progetto! D\u00ec loro che btrfs sar\u00e0 pronto tra 18 mesi\u00bb. Lascio che siano le persone a decidere quando btrfs raggiunger\u00e0 lo stato di \u00abpronto per l'uso aziendale\u00bb, specialmente per quelle nuove e attraenti funzionalit\u00e0 avanzate che avrebbero dovuto competere con ZFS, ma non credo che sia discutibile che ci\u00f2 non sia avvenuto entro 18 mesi. <\/p>\n E anche prima che Sun si disperdesse, molte aziende che avevano inviato i loro rappresentanti all'incontro rifiutarono la partecipazione degli ingegneri ai lavori su btrfs, e questo, ovviamente, non aiut\u00f2. Ma probabilmente era legato al fatto che le aziende - organizzazioni razionali che prendono decisioni sui ritorni sugli investimenti - e il finanziamento di un nuovo file system non aveva lo stesso senso di dire alla gente che Linux avrebbe avuto una risposta a ZFS. <\/p>\n Guardando indietro, si pu\u00f2 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\u00f9 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\u00e0 rispetto a server<\/a> SunFire E10k Sparc a 100000 dollari, che Sun chiamava \u2018punto\u2019 nel \u2018dot Com\u2019. <\/p>\n La questione \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 voler guadagnare abbastanza da poter andare in pensione un giorno. Questo, a sua volta, significa che devo capire bene come apportare valore al mio datore di lavoro, almeno dieci volte superiore al mio stipendio. Se riesco a farlo continuando a lavorare con il codice sorgente aperto e aiutando altre aziende a guadagnare, affinch\u00e9 siano pronte a contribuire a ext4, beh, questa \u00e8 una parte della sfida e il motivo per cui amo lavorare con il codice sorgente aperto. <\/p>\n E, tornando al Codice di Comportamento, dir\u00f2 che quasi tutti i maintainer dei principali file system hanno supportato il Codice non per vaghe considerazioni liberali. \u00c8 perch\u00e9 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 \u00e8 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. <\/p>\n In alcuni casi, le preoccupazioni erano infondate; ad esempio, Linus urlava a un senior developer che avrebbe dovuto sapere meglio e con cui Linus si era incontrato personalmente nella maggior parte dei casi, e avevano gi\u00e0 una relazione consolidata. Il problema \u00e8 che i principianti non lo sapevano e si spaventavano - \u2018e se Linus mi umilia in pubblico come ha fatto con Steve\u2019, non capendo che in pratica ci\u00f2 non accadr\u00e0. Ecco perch\u00e9 abbiamo il CoC; non \u00e8 per noi, ingegneri senior, ma per supportare i giovani ingegneri nei nostri team, che vogliamo formare affinch\u00e9 un giorno possano sostituirci quando sar\u00e0 il momento di andare in pensione, o ci investir\u00e0 un autobus, o in qualche altro modo lasceremo questo mondo effimero. <\/p>\n Non dimenticate i 50-100 anni-uomo di lavoro necessari per creare un file system pronto all'uso in un ambiente aziendale. Abbiamo bisogno di tutti gli ingegneri che possiamo attrarre, e molti di noi svolgono lavoro extra nel loro tempo libero, perch\u00e9 ci teniamo. Creare un file system di alta qualit\u00e0 \u00e8 un lavoro di squadra, e abbiamo bisogno di ogni ingegnere talentuoso che possiamo reclutare. Anche se un ingegnere \u00e8 un programmatore super 10 volte migliore, se alla fine allontana molti altri ingegneri che potrebbero lavorare sui test, sull'ottimizzazione delle prestazioni, ecc., semplicemente non vale la pena permettere a qualcuno di essere un bastardo. <\/p><\/blockquote>\n\n
\n
\n