È stata pubblicata la seconda intervista con Eduard Shishkin, sviluppatore del file system Reiser4.
Per iniziare, ricorda ai lettori dove e per chi lavori.
Lavoro come Principal Storage Architect presso Huawei Technologies, centro di ricerca tedesco. Nel reparto virtualizzazione mi occupo di vari aspetti legati allo storage dei dati. Le mie attività non sono legate ad un sistema operativo specifico.
Ti stai attualmente impegnando nel ramo principale del kernel?
Molto raramente e solo se il mio datore di lavoro lo richiede. L'ultima volta è stata circa tre anni fa, ho inviato patch per aumentare il throughput per lo storage condiviso sugli host utilizzando il protocollo 9p (un altro nome per questa attività è VirtFS). Qui va fatta una nota importante: anche se lavoro con Linux da molto tempo, non ne sono mai stato un fan, cioè “respiro uniformemente”, come tutto il resto. In particolare, se noto un difetto, posso segnalarlo al massimo una volta. E così che tu possa seguire qualcuno e persuaderlo, questo non accadrà.
Ricordo che l'ultima volta, dieci anni fa, eri piuttosto critico nei confronti dello stile di sviluppo del kernel. Dal tuo punto di vista (o forse aziendale), è cambiato qualcosa, la community è diventata più reattiva oppure no? Se no, chi pensi che sia la colpa?
Non ho mai visto alcun cambiamento in meglio. Il problema principale della comunità è la sostituzione della scienza con tecnologie politiche, relazioni personali, opinione della maggioranza, populismo, consigli di “voci interiori”, compromessi marci, qualsiasi cosa diversa dalla scienza. L'informatica, qualunque cosa si voglia dire, è innanzitutto una scienza esatta. E se qualcuno inizia a proclamare il proprio valore per 2x2, diverso da 4, sotto la bandiera del "metodo Linux" o sotto qualche altra bandiera, allora è improbabile che ciò porti altro che danno.
Tutti i problemi sono dovuti innanzitutto all’incompetenza e alla mancanza di educazione di chi prende le decisioni. Se un manager è incompetente, non è in grado di prendere una decisione obiettiva e adeguata. Se è anche incolto, non riesce a trovare uno specialista competente che gli dia i giusti consigli. Con un'alta probabilità, la scelta ricadrà su un truffatore che dice "cose apparentemente corrette". Un ambiente corrotto si sviluppa sempre attorno a leader solitari incompetenti. Del resto la storia non conosce eccezioni al riguardo, e la comunità ne è la conferma più lampante.
Come valuti i progressi nello sviluppo di Btrfs? Questa FS si è sbarazzata delle malattie infantili? Come lo posizioni per te stesso: come FS “per la casa” o anche per uso aziendale?
Non me ne sono sbarazzato. Tutto ciò che ho menzionato 11 anni fa è ancora attuale oggi. Uno dei problemi di Btrfs che lo rende inadatto a esigenze serie è il problema dello spazio libero. Non sto nemmeno parlando del fatto che all'utente viene chiesto di correre allo store per un nuovo disco in situazioni in cui qualsiasi altro FS mostrerebbe molto spazio libero sulla partizione. Anche l'impossibilità di completare un'operazione su un volume logico a causa della mancanza di spazio libero non è la cosa peggiore. La cosa peggiore è che un utente non privilegiato può quasi sempre, aggirare eventuali quote del disco, privare tutti dello spazio libero in un tempo abbastanza breve.
Sembra così (testato per il kernel Linux 5.12). Sul sistema appena installato viene avviato uno script che crea in un ciclo file con determinati nomi nella directory home, scrive i dati su di essi con determinati offset e quindi elimina questi file. Dopo un minuto di esecuzione di questo script, non accade nulla di insolito. Dopo cinque minuti la porzione di spazio occupato sulla partizione aumenta leggermente. Dopo due-tre ore si raggiunge il 50% (con un valore iniziale del 15%). E dopo cinque o sei ore di lavoro, lo script si blocca con l'errore "non c'è spazio libero sulla partizione". Successivamente, non sarai più in grado di scrivere nemmeno un file 4K sulla tua partizione.
Si verifica una situazione interessante: alla fine non hai scritto nulla sulla partizione e tutto lo spazio libero (circa l'85%) è scomparso da qualche parte. L'analisi di una sezione soggetta a tale attacco rivelerà molti nodi dell'albero contenenti un solo elemento (un oggetto dotato di una chiave), di dimensioni diversi byte. Cioè, il contenuto che in precedenza occupava il 15% dello spazio su disco si è rivelato uniformemente "sparso" sull'intera partizione in modo che non ci fosse nessun posto dove scrivere un nuovo file, perché la sua chiave è più grande di tutte quelle esistenti e quella libera i blocchi sulla partizione sono esauriti.
Inoltre, tutto questo avviene già nella configurazione base di Btrfs (senza snapshot, sottovolumi, ecc.), e non importa come decidi di archiviare i corpi dei file in quel FS (come "frammenti" in un albero o come estensioni di blocchi non formattati) - il risultato finale sarà lo stesso.
Non sarai in grado di sottoporre altri file system upstream a un simile attacco (non importa cosa ti dicono). Ho spiegato la causa del problema molto tempo fa: si tratta di una completa perversione del concetto di B-tree in Btrfs, che ne rende possibile la degenerazione spontanea o intenzionale. In particolare, sotto determinati carichi, il vostro file system “cade a pezzi” continuamente durante il funzionamento da solo, senza aiuto esterno. È chiaro che tutti i tipi di processi in background "pressanti" salveranno la situazione solo sui singoli desktop.
Sui server collettivi, un utente malintenzionato sarà sempre in grado di “superarli”. L'amministratore di sistema non sarà nemmeno in grado di determinare chi esattamente lo ha vittima di bullismo. Il modo più veloce per risolvere questo problema in Btrfs è ripristinare la struttura di un normale albero B, ad es. riprogettando il formato del disco e riscrivendo porzioni significative del codice Btrfs. Ci vorranno 8-10 anni, compreso il debug, a condizione che gli sviluppatori seguano rigorosamente gli articoli originali sugli algoritmi e sulle strutture dati rilevanti e non giochino al gioco del "telefono rotto", come è consuetudine (e incoraggiato) nel "Linux modo".
Qui bisogna aggiungere anche il tempo necessario agli sviluppatori per comprendere tutto questo. È qui che diventa più difficile. In ogni caso, 10 anni non sono bastati per capire. Ebbene, fino ad allora non puoi sperare in un miracolo. Non avverrà sotto forma di un’opzione di montaggio “di cui tu ed io non eravamo a conoscenza” o sotto forma di una patch che è “solo una questione di affari” da preparare. Per ciascuna di queste “correzioni” affrettate presenterò un nuovo scenario di degenerazione. Gli alberi B sono uno dei miei argomenti preferiti e devo dire che queste strutture non tollerano libertà con se stesse!
Come posso posizionare Btrfs per me stesso? Come qualcosa che non può assolutamente essere chiamato file system, tanto meno utilizzato. Perché, per definizione, FS è un sottosistema del sistema operativo responsabile della gestione efficace della risorsa “spazio su disco”, cosa che non vediamo nel caso di Btrfs. Ebbene, immagina di essere venuto al negozio per comprare un orologio per non arrivare in ritardo al lavoro, e invece dell'orologio ti hanno venduto una griglia elettrica con timer per un massimo di 30 minuti. Quindi, la situazione con Btrfs è ancora peggiore.
Esaminando le mailing list, mi imbatto spesso nell'affermazione che la gestione efficace dello spazio su disco non è più rilevante a causa dell'economicità delle unità. Questa è una totale assurdità. Senza un efficace gestore dello spazio su disco, il sistema operativo diventerà vulnerabile e inutilizzabile. Indipendentemente dalla capacità dei dischi della tua macchina.
Vorrei chiedere un commento sull'interruzione del supporto Btrfs in RHEL.
Non c'è niente di speciale da commentare qui, tutto è molto chiaro. L'avevano anche come "anteprima tecnologica". Quindi, non ho seguito proprio questa “anteprima”. Non lasciare che questa etichetta rimanga appesa per sempre! Ma non possono lanciare un prodotto difettoso fin dalla progettazione con pieno supporto. RHEL è un'impresa, cioè prescritte relazioni merce-denaro. Red Hat non può intimidire gli utenti come fa nella mailing list Btrfs. Immaginate la situazione: un cliente che ha pagato i suoi soldi duramente guadagnati per il disco e anche voi per il supporto, vuole capire dove è andato a finire il suo spazio su disco dopo che non ha scritto nulla. Cosa gli risponderai a questo?
Ulteriore. Tra i clienti di Red Hat figurano grandi banche e borse molto note. Immagina cosa accadrebbe se fossero soggetti ad attacchi DoS basati sulla vulnerabilità menzionata in Btrfs. Chi pensi che sia responsabile di questo? A chi sta per puntare il dito sulla riga della licenza GPL, dove c'è scritto che l'autore non è responsabile di nulla, dirò subito: “nascondetelo!” Red Hat risponderà, e in modo tale che non sembrerà abbastanza! Ma so che Red Hat non si trova ad affrontare questo tipo di problema, dato il suo team particolarmente forte di ingegneri QA con cui ho avuto l'opportunità di lavorare a stretto contatto nel mio tempo.
Perché alcune aziende continuano a supportare Btrfs nei loro prodotti aziendali?
Tieni presente che il prefisso "enterprise" nel nome del prodotto non significa molto. L'impresa è una misura di responsabilità incorporata nel rapporto contrattuale con il cliente. Conosco una sola azienda basata su GNU/Linux: RHEL. Tutto il resto, dal mio punto di vista, si presenta solo come un'impresa, ma non lo è. E infine, se c'è una domanda per qualcosa, allora ci sarà sempre un'offerta (nel nostro caso si tratta del citato "supporto"). C'è richiesta assolutamente di tutto, incl. e software inutilizzabile. Come si forma tale domanda e chi la alimenta è un altro argomento.
Quindi, non salterei a nessuna conclusione dopo che si dice che Facebook abbia distribuito Btrfs sui suoi server. Inoltre, consiglierei di mantenere segreti gli indirizzi di tali server per i motivi sopra indicati.
Perché ultimamente sono stati fatti così tanti sforzi per ripulire il codice XFS? Dopotutto, inizialmente si tratta di un file system di terze parti ed ext4 è stabile da molto tempo e ha continuità rispetto alle versioni precedenti altrettanto stabili. Che interesse ha Red Hat per XFS? Ha senso sviluppare attivamente due file system con scopi simili: ext4 e XFS?
Non ricordo cosa lo abbia motivato. È del tutto possibile che l'iniziativa provenga dai clienti Red Hat. Ricordo che furono effettuate ricerche di questo tipo: su alcuni file system a monte, furono creati un numero gigantesco di oggetti su drive high-end di nuova generazione. Secondo i risultati, XFS si è comportato meglio di ext4. Così iniziarono a promuoverlo come il più promettente. In ogni caso qui non cercherei nulla di sensazionale.
Per me è come se avessero sostituito il punteruolo con il sapone. Non ha senso sviluppare ext4 e XFS. Entrambi in parallelo e tra cui scegliere. Non ne verrà fuori niente di buono. Tuttavia, in natura ci sono spesso situazioni in cui c'è molto potenziale di crescita, ma non c'è spazio per crescere. In questo caso, sorgono varie nuove escrescenze stranamente brutte, su cui tutti puntano il dito ("Oh, guarda, cosa non vedrai in questa vita!").
Pensi che il problema della violazione del livello sia stato risolto (in senso negativo) con l'avvento delle funzioni di crittografia in ext4, F2FS (per non parlare del RAID in Btrfs)?
In generale, l'introduzione di qualsiasi livello e la decisione sulla loro non violazione è solitamente una questione di politica e non mi impegno a commentare nulla qui. Gli aspetti oggettivi della violazione del livello interessano poco a nessuno, ma possiamo considerarne alcuni usando l'esempio della violazione “dall'alto”, ovvero l'implementazione nel FS di funzionalità già esistenti sul livello del blocco. Tale “violazione” è giustificata solo con rare eccezioni. Per ciascuno di questi casi, è necessario prima dimostrare due cose: che è realmente necessario e che la progettazione del sistema non verrà danneggiata in tal modo.
Ad esempio, il mirroring, che tradizionalmente è stata un'attività del livello di blocco, ha senso implementarlo a livello di file system. Per vari motivi. Ad esempio, il danneggiamento “silenzioso” dei dati (bit rot) si verifica sulle unità disco. Questo accade quando il dispositivo funziona correttamente, ma i dati del blocco vengono inaspettatamente danneggiati sotto l'influenza di un quanto gamma duro emesso da un quasar distante, ecc. La cosa peggiore è se questo blocco risulta essere un blocco del sistema FS (superblocco, blocco bitmap, nodo dell'albero di archiviazione, ecc.), perché ciò porterà sicuramente al panico del kernel.
Tieni presente che i mirror offerti dal block layer (il cosiddetto RAID 1) non ti eviteranno da questo problema. Beh, davvero: qualcuno dovrebbe controllare i checksum e leggere la replica in caso di guasto? Inoltre, è opportuno eseguire il mirroring non solo di tutto, ma solo dei metadati. Alcuni dati importanti (ad esempio file eseguibili di applicazioni critiche) possono essere archiviati come metadati. In questo caso ricevono le stesse garanzie di sicurezza. È logico affidare la protezione dei dati rimanenti ad altri sottosistemi (forse anche alle applicazioni utente): abbiamo fornito tutte le condizioni necessarie per questo.
Tali mirror “economici” hanno il diritto di esistere e possono essere organizzati in modo efficace solo a livello di file system. Altrimenti, la violazione della stratificazione ingombra un sottosistema con codice duplicato a vantaggio di alcuni vantaggi microscopici. Un esempio lampante di ciò è l'implementazione di RAID-5 utilizzando FS. Tali soluzioni (proprio RAID/LVM nel file system) uccidono quest'ultimo in termini architettonici. Va inoltre notato che la violazione della stratificazione viene “messa in funzione” da vari tipi di truffatori di marketing. In assenza di idee, ai sottosistemi vengono aggiunte funzionalità che sono state implementate da tempo a livelli vicini, questa viene presentata come una nuova funzionalità estremamente utile e viene attivamente promossa.
Reiser4 è stato accusato di aver violato i livelli “dal basso”. Basandosi sul fatto che il file system non è monolitico, come tutti gli altri, ma modulare, è stata fatta l'ipotesi infondata che faccia quello che dovrebbe fare il livello superiore (VFS).
È possibile parlare della morte di ReiserFS v3.6 e, ad esempio, di JFS? Ultimamente non hanno ricevuto quasi nessuna attenzione nel nucleo. Sono obsoleti?
Qui dobbiamo definire cosa significa la morte di un prodotto software. Da un lato vengono utilizzati con successo (dopo tutto sono stati creati per questo), il che significa che vivono. D'altra parte, non posso parlare per JFS (non ne so molto), ma ReiserFS (v3) è molto difficile da adattare alle nuove tendenze (testato nella pratica). Ciò significa che in futuro gli sviluppatori presteranno attenzione non ad esso, ma a quelli che sono più facili da adattare. Da questo lato si scopre che, ahimè, è morto in termini architettonici. Non manipolerei affatto il concetto di “moralmente obsoleto”. Si applica bene, ad esempio, a un guardaroba, ma non ai prodotti software. C'è un concetto di inferiorità e superiorità in qualcosa. Posso assolutamente dire che ReserFS v3 è ora inferiore a Reiser4 in tutto, ma in alcuni tipi di carico di lavoro è superiore a tutti gli altri FS upstream.
Conosci lo sviluppo di FS Tux3 e HAMMER/HAMMER2 (FS per DragonFly BSD)?
Si lo sappiamo. In Tux3 una volta ero interessato alla tecnologia delle loro istantanee (i cosiddetti “puntatori di versione”), ma in Reiser4 molto probabilmente seguiremo una strada diversa. Ho pensato a lungo al supporto degli snapshot e non ho ancora deciso come implementarli per semplici volumi Reiser4. Il fatto è che la nuova tecnica del contatore di riferimento “pigro” proposta da Ohad Rodeh funziona solo per i B-tree. Non li abbiamo. Per quelle strutture dati utilizzate in Reiesr4, i contatori "pigri" non sono definiti: per introdurli è necessario risolvere alcuni problemi algoritmici, che nessuno ha ancora affrontato.
Secondo HAMMER: ho letto un articolo del creatore. Non interessato. Ancora una volta, B-tree. Questa struttura dei dati è irrimediabilmente obsoleta. Lo abbiamo abbandonato nel secolo scorso.
Come valuti la crescente domanda di FS di cluster di rete come CephFS/GlusterFS/ecc? Questa richiesta significa uno spostamento delle priorità degli sviluppatori verso il FS di rete e un'attenzione insufficiente al FS locale?
Sì, si è verificato un tale cambiamento nelle priorità. Lo sviluppo dei file system locali è stagnante. Purtroppo, fare qualcosa di significativo per i volumi locali ora è piuttosto difficile e non tutti possono farlo. Nessuno vuole investire nel loro sviluppo. È più o meno come chiedere a un'organizzazione commerciale di stanziare denaro per la ricerca matematica: senza alcun entusiasmo ti chiederanno come puoi guadagnare con un nuovo teorema. Ora un FS locale è qualcosa che appare magicamente “fuori dagli schemi” e “dovrebbe sempre funzionare”, e se non funziona, provoca lamentele senza risposta come: “Sì, cosa stanno pensando!”
Da qui la scarsa attenzione alle FS locali, anche se in quel settore c’è ancora molto da lavorare. E sì, tutti si sono rivolti allo storage distribuito, costruito sulla base di file system locali già esistenti. Va molto di moda adesso. La frase “Big Data” provoca in molti una scarica di adrenalina, associandola a conferenze, workshop, grandi stipendi, ecc.
Quanto è ragionevole, in linea di principio, implementare il file system di rete nello spazio del kernel piuttosto che nello spazio dell'utente?
Un approccio molto ragionevole che non è stato ancora implementato da nessuna parte. In generale, la questione di quale spazio debba essere implementato un file system di rete è una “arma a doppio taglio”. Bene, diamo un'occhiata a un esempio. Il client ha registrato i dati su una macchina remota. Sono caduti nella cache delle sue pagine sotto forma di pagine sporche. Questo è il lavoro di un file system di rete "thin gateway" nello spazio del kernel. Quindi il sistema operativo prima o poi ti chiederà di scrivere quelle pagine su disco per liberarle. Quindi entra in gioco il modulo FS di rete di inoltro IO (invio). Determina a quale macchina server (nodo server) andranno queste pagine.
Poi subentra lo stack di rete (e, come sappiamo, è implementato nello spazio del kernel). Successivamente, il nodo del server riceve quel pacchetto con dati o metadati e istruisce il modulo di archiviazione backend (ovvero l'FS locale che opera nello spazio del kernel) per registrare tutte queste cose. Quindi, abbiamo ridotto la questione a dove dovrebbero funzionare i moduli “invio” e “ricezione”. Se uno qualsiasi di questi moduli viene eseguito nello spazio utente, ciò porterà inevitabilmente al cambio di contesto (a causa della necessità di utilizzare i servizi del kernel). Il numero di tali interruttori dipende dai dettagli di implementazione.
Se sono presenti molti switch di questo tipo, il throughput di archiviazione (prestazioni I/O) diminuirà. Se il tuo spazio di archiviazione back-end è costituito da dischi lenti, non noterai un calo significativo. Ma se disponi di dischi veloci (SSD, NVRAM, ecc.), il cambio di contesto diventa già un "collo di bottiglia" e, risparmiando sul cambio di contesto, le prestazioni possono essere aumentate in modo significativo. Il modo standard per risparmiare denaro è spostare i moduli nello spazio del kernel. Ad esempio, abbiamo scoperto che lo spostamento del server 9p da QEMU al kernel sulla macchina host porta a un aumento di tre volte delle prestazioni VirtFS.
Questo, ovviamente, non è un FS di rete, ma rispecchia in pieno l'essenza delle cose. Lo svantaggio di questa ottimizzazione sono i problemi di portabilità. Per alcuni, quest’ultimo potrebbe essere fondamentale. Ad esempio, GlusterFS non ha alcun modulo nel kernel. Grazie a ciò, ora funziona su molte piattaforme, incluso NetBSD.
Quali concetti potrebbero mutuare i FS locali da quelli di rete e viceversa?
Al giorno d'oggi, gli FS di rete, di regola, hanno componenti aggiuntivi rispetto agli FS locali, quindi non capisco bene come si possa prendere in prestito qualcosa da quest'ultimo. Ebbene, consideriamo un'azienda di 4 dipendenti, in cui ognuno fa le sue cose: uno distribuisce, un altro invia, il terzo riceve, il quarto immagazzina. E la domanda, cosa può prendere in prestito l'azienda dal suo dipendente che lo immagazzina, suona in qualche modo errata (quello che avrebbe potuto prendere in prestito da lui lo ha già da molto tempo).
Ma i FS locali hanno molto da imparare da quelli di rete. In primo luogo, dovresti imparare da loro come aggregare volumi logici ad alto livello. Ora il cosiddetto I file system locali “avanzati” aggregano volumi logici utilizzando esclusivamente la tecnologia del “dispositivo virtuale” presa in prestito da LVM (quella stessa violazione infettiva della stratificazione implementata per la prima volta in ZFS). In altre parole, la traduzione degli indirizzi virtuali (numeri di blocco) in indirizzi reali e viceversa avviene a livello basso (cioè dopo che il file system ha emesso una richiesta I/O).
Tieni presente che l'aggiunta e la rimozione di dispositivi su volumi logici (non mirror) disposti sullo strato di blocchi porta a problemi sui quali i fornitori di tali "funzionalità" tacciono modestamente. Parlo di frammentazione sui dispositivi reali, che può raggiungere valori mostruosi, mentre su un dispositivo virtuale va tutto bene. Tuttavia, poche persone sono interessate ai dispositivi virtuali: tutti sono interessati a ciò che accade sui tuoi dispositivi reali. Ma l'FS simile a ZFS (così come qualsiasi FS insieme a LVM) funziona solo con i dispositivi del disco virtuale (assegna gli indirizzi del disco virtuale tra quelli liberi, deframmenta questi dispositivi virtuali, ecc.). E non hanno idea di cosa sta succedendo sui dispositivi reali!
Ora immagina di avere una frammentazione pari a zero sul dispositivo virtuale (ovvero, di avere solo un'estensione enorme che vive lì), di aggiungere un disco al tuo volume logico, quindi rimuovere un altro disco casuale dal tuo volume logico e quindi ribilanciarlo. E così tante volte. Non è difficile immaginare che sul dispositivo virtuale avrai ancora la stessa misura di vita, ma sui dispositivi reali non vedrai nulla di buono.
La cosa peggiore è che non sei nemmeno in grado di correggere questa situazione! L'unica cosa che puoi fare qui è chiedere al file system di deframmentare il dispositivo virtuale. Ma lei ti dirà che lì va tutto benissimo: c'è solo una misura, la frammentazione è zero e non può essere migliore! Pertanto, i volumi logici disposti a livello di blocco non sono destinati all'aggiunta/rimozione ripetuta di dispositivi. In senso buono, è sufficiente assemblare un volume logico a livello di blocco solo una volta, passarlo al file system e quindi non fare nient'altro con esso.
Inoltre, la combinazione di sottosistemi FS+LVM indipendenti non consente di tenere conto della diversa natura delle unità da cui vengono aggregati i volumi logici. In effetti, supponiamo di aver assemblato un volume logico da HDD e dispositivi a stato solido. Ma il primo richiederà la deframmentazione e il secondo no. Per quest'ultimo è necessario emettere richieste di scarto, ma per il primo no, ecc. Tuttavia, in questa combinazione è abbastanza difficile dimostrare tale selettività.
Tieni presente che dopo aver creato il tuo LVM sul file system, la situazione non migliora molto. Inoltre, così facendo si mette effettivamente fine alla prospettiva di migliorarlo in futuro. Questo è molto brutto. Sulla stessa macchina possono convivere tipi diversi di azionamenti. E se il file system non distingue tra loro, chi lo farà?
Un altro problema è in attesa del cosiddetto. File system "Write-Anywhere" (questo include anche Reiser4, se hai specificato il modello transazionale appropriato durante il montaggio). Tali file system devono fornire strumenti di deframmentazione senza precedenti in termini di potenza. E il gestore del volume di basso livello non aiuta qui, ma si limita a interferire. Il fatto è che con un tale gestore, il tuo FS memorizzerà una mappa di blocchi liberi di un solo dispositivo, virtuale. Di conseguenza, puoi solo deframmentare un dispositivo virtuale. Ciò significa che il tuo deframmentatore funzionerà per molto, molto tempo su un unico enorme spazio di indirizzi virtuali.
E se hai molti utenti che eseguono sovrascritture casuali, l'effetto utile di tale deframmentazione sarà ridotto a zero. Il vostro sistema inizierà inevitabilmente a rallentare, e non vi resterà che con le mani in mano davanti alla deludente diagnosi “design rotto”. Diversi deframmentatori in esecuzione sullo stesso spazio di indirizzi interferiranno solo tra loro. La questione è completamente diversa se mantieni la tua mappa di blocchi liberi per ogni dispositivo reale. Ciò parallelizzerà efficacemente il processo di deframmentazione.
Ma questo può essere fatto solo se si dispone di un gestore di volumi logici di alto livello. File system locali con tali gestori non esistevano in precedenza (almeno, non li conosco). Solo i file system di rete (ad esempio GlusterFS) avevano tali gestori. Un altro esempio molto importante è l'utilità di controllo dell'integrità del volume (fsck). Se memorizzi la tua mappa indipendente di blocchi liberi per ciascun sottovolume, la procedura per controllare un volume logico può essere parallelizzata in modo efficace. In altre parole, i volumi logici con manager di alto livello scalano meglio.
Inoltre, con i gestori di volume di basso livello non sarai in grado di organizzare istantanee a tutti gli effetti. Con i file system simili a LVM e ZFS, puoi acquisire solo istantanee locali, ma non istantanee globali. Le istantanee locali ti consentono di eseguire il rollback istantaneo solo delle normali operazioni sui file. E nessuno eseguirà il rollback delle operazioni con volumi logici (aggiunta/rimozione di dispositivi). Consideriamolo con un esempio. Ad un certo punto, quando si dispone di un volume logico di due dispositivi A e B contenente 100 file, si scatta un'istantanea del sistema S e quindi si creano altri cento file.
Successivamente, aggiungi il dispositivo C al tuo volume e infine esegui il rollback del sistema allo snapshot S. Domanda: quanti file e dispositivi contiene il tuo volume logico dopo il rollback a S? Ci saranno 100 file, come avrai intuito, ma ci saranno 3 dispositivi: si tratta degli stessi dispositivi A, B e C, anche se al momento della creazione dell'istantanea c'erano solo due dispositivi nel sistema (A e B ). L'operazione di aggiunta del dispositivo C non è stata ripristinata e se ora rimuovi il dispositivo C dal computer, i tuoi dati verranno danneggiati, quindi prima di eliminare dovrai prima eseguire un'operazione costosa per rimuovere il dispositivo dal volume logico di ribilanciamento, che distribuirà tutti i dati dal dispositivo C ai dispositivi A e B. Ma se il tuo FS supportasse le istantanee globali, tale ribilanciamento non sarebbe richiesto e, dopo un rollback istantaneo su S, potresti rimuovere in sicurezza il dispositivo C dal computer.
Quindi, le istantanee globali sono utili perché ti consentono di evitare la costosa rimozione (aggiunta) di un dispositivo da un volume logico (a un volume logico) con una grande quantità di dati (ovviamente, se ti ricordi di "istantanea" del tuo sistema al momento giusto). Lascia che ti ricordi che la creazione di istantanee e il ripristino del file system su di esse sono operazioni istantanee. Potrebbe sorgere la domanda: com'è possibile ripristinare istantaneamente un'operazione su un volume logico che ha richiesto tre giorni? Ma è possibile! A condizione che il file system sia progettato correttamente. L'idea di queste "istantanee 3D" mi è venuta tre anni fa e l'anno scorso ho brevettato questa tecnica.
La prossima cosa che i FS locali dovrebbero imparare da quelli di rete è memorizzare i metadati su dispositivi separati nello stesso modo in cui i FS di rete li memorizzano su macchine separate (i cosiddetti server di metadati). Esistono applicazioni che funzionano principalmente con i metadati e queste applicazioni possono essere notevolmente accelerate inserendo i metadati su costosi dispositivi di archiviazione ad alte prestazioni. Con la combinazione FS+LVM, non sarai in grado di dimostrare tale selettività: LVM non sa cosa c'è nel blocco che gli hai passato (dati lì o metadati).
Non otterrai molti vantaggi dall’implementazione del tuo LVM di basso livello nel FS rispetto alla combinazione FS+LVM, ma quello che puoi fare molto bene è ingombrare il FS in modo che in seguito diventi impossibile lavorare con il suo codice. ZFS e Btrfs, che si sono affrettati con i dispositivi virtuali, sono tutti chiari esempi di come la violazione della stratificazione uccida il sistema in termini architettonici. Allora, perché sono tutto questo? Inoltre, non è necessario installare il proprio LVM di basso livello nel file system. È invece necessario aggregare i dispositivi in volumi logici ad alto livello, come fanno alcuni file system di rete con macchine diverse (nodi di archiviazione). È vero, lo fanno in modo disgustoso a causa dell'uso di algoritmi errati.
Esempi di algoritmi assolutamente terribili sono il traduttore DHT nel file system GlusterFS e la cosiddetta mappa CRUSH nel file system Ceph. Nessuno degli algoritmi che ho visto mi ha soddisfatto in termini di semplicità e buona scalabilità. Quindi ho dovuto ricordarmi l'algebra e inventare tutto da solo. Nel 2015, mentre sperimentavo i bundle rispetto alle funzioni hash, ho ideato e brevettato qualcosa che fa al caso mio. Ora posso dire che il tentativo di mettere in pratica tutto questo ha avuto successo. Non vedo alcun problema di scalabilità nel nuovo approccio.
Sì, ogni sottovolume richiederà una struttura separata come un superblocco in memoria. È molto spaventoso? In generale, non so chi "farà bollire l'oceano" e creerà volumi logici di centinaia di migliaia o più dispositivi su una macchina locale. Se qualcuno può spiegarmelo gli sarò molto grato. Nel frattempo per me questa è una stronzata di marketing.
In che modo le modifiche nel sottosistema del dispositivo a blocchi del kernel (ad esempio, la comparsa di blk-mq) hanno influenzato i requisiti per l'implementazione di FS?
Non hanno avuto alcun impatto. Non so cosa accadrebbe sul livello dei blocchi che renderebbe necessario progettare un nuovo FS. L'interfaccia di interazione di questi sottosistemi è molto scarsa. Dal lato del driver, il FS dovrebbe essere influenzato solo dalla comparsa di nuovi tipi di unità, alle quali verrà adattato prima il livello di blocco, e poi il FS (per reiser4 questo significherà la comparsa di nuovi plugin).
L’emergere di nuovi tipi di media (ad esempio, SMR o l’ubiquità degli SSD) comporta sfide fondamentalmente nuove per la progettazione di file system?
SÌ. E questi sono normali incentivi per lo sviluppo delle FS. Le sfide possono essere diverse e del tutto inaspettate. Ad esempio, ho sentito parlare di unità in cui la velocità di un'operazione di I/O dipende fortemente dalla dimensione di un dato e dal suo offset. In Linux, dove la dimensione del blocco FS non può superare la dimensione della pagina, tale unità non mostrerà tutte le sue capacità per impostazione predefinita. Tuttavia, se il tuo file system è progettato correttamente, c'è la possibilità di ottenerne molto di più.
Quante persone oltre a te lavorano attualmente con il codice Reiser4?
Meno di quanto vorrei, ma non avverto nemmeno una grave carenza di risorse. Sono più che soddisfatto del ritmo di sviluppo di Reiser4. Non "guiderò i cavalli": questa non è l'area giusta. Ecco, “se guidi più piano, andrai avanti!” Un file system moderno è il sottosistema del kernel più complesso, le cui decisioni di progettazione sbagliate possono annullare anni successivi di lavoro umano.
Offrendo volontari per realizzare qualcosa, garantisco sempre che gli sforzi porteranno sicuramente al risultato corretto, che può essere richiesto per esigenze serie. Come capisci, non possono esserci molte di queste garanzie contemporaneamente. Allo stesso tempo, non sopporto le “figure” che promuovono spudoratamente “caratteristiche” di software evidentemente inutilizzabili, ingannando centinaia di utenti e sviluppatori, e allo stesso tempo si siedono e sorridono ai summit del kernel.
Qualche azienda ha espresso la volontà di sostenere lo sviluppo di Reiser4?
Sì, c'erano tali proposte, incl. e da un importante fornitore. Ma per questo ho dovuto trasferirmi in un altro paese. Purtroppo non ho più 30 anni, non posso staccarmi e andarmene così al primo fischio.
Quali funzionalità mancano attualmente a Reiser4?
Non esiste una funzione di "ridimensionamento" per i volumi semplici, simile a quella trovata in ReiserFS(v3). Inoltre, le operazioni sui file con il flag DIRECT_IO non sarebbero dannose. Successivamente, mi piacerebbe poter separare un volume in “sottovolumi semantici”, che non hanno una dimensione fissa e che possono essere montati come volumi indipendenti. Questi problemi sono utili per i principianti che vogliono cimentarsi con la “cosa reale”.
E infine, vorrei avere volumi logici di rete con implementazione e amministrazione semplici (gli algoritmi moderni lo consentono già). Ma ciò che Reiser4 sicuramente non avrà mai è RAID-Z, scrub, cache di spazio libero, variabili a 128 bit e altre sciocchezze di marketing sorte sullo sfondo di una carenza di idee tra gli sviluppatori di alcuni file system.
Tutto ciò che potrebbe essere necessario può essere implementato dai plugin?
Se parliamo solo in termini di interfacce e plugin (moduli) che le implementano, allora non tutto. Ma se introduci anche le relazioni su queste interfacce, allora, tra le altre cose, avrai i concetti di polimorfismi superiori, con cui puoi già cavartela. Immagina di aver ipoteticamente congelato un sistema runtime orientato agli oggetti, cambiato il valore del puntatore dell'istruzione in modo che punti a un altro plugin che implementa la stessa interfaccia X, e quindi sbloccato il sistema in modo che continui l'esecuzione.
Se l’utente finale non nota tale “sostituzione”, allora diciamo che il sistema ha un polimorfismo di ordine zero nell’interfaccia X (o che il sistema è eterogeneo nell’interfaccia X, che è la stessa cosa). Se ora non solo hai un insieme di interfacce, ma hai anche relazioni su di esse (grafico dell'interfaccia), allora puoi introdurre polimorfismi di ordine superiore, che caratterizzeranno l'eterogeneità del sistema già nel “vicinato” di qualsiasi interfaccia. Ho introdotto una classificazione del genere molto tempo fa, ma sfortunatamente non è mai avvenuta.
Quindi, con l'aiuto di plugin e polimorfismi più elevati, puoi descrivere qualsiasi caratteristica nota, nonché "prevedere" quelle che non sono mai state nemmeno menzionate. Non sono stato in grado di dimostrarlo rigorosamente, ma non conosco ancora un controesempio. In generale, questa domanda mi ha ricordato il “Programma Erlangen” di Felix Klein. Un tempo cercò di rappresentare tutta la geometria come una branca dell'algebra (in particolare, la teoria dei gruppi).
Veniamo ora alla domanda principale: come vanno le cose con la promozione di Reiser4 al nucleo principale? Ci sono state pubblicazioni sull'architettura di questo file system di cui hai parlato nell'ultima intervista? Quanto è rilevante questa domanda dal tuo punto di vista?
In generale sono tre anni che chiediamo l'inserimento nel ramo principale. L'ultimo commento di Reiser nel thread pubblico in cui è stata effettuata la richiesta di pull è rimasto senza risposta. Quindi tutte le ulteriori domande non riguardano noi. Personalmente non capisco perché dobbiamo "fonderci" in un sistema operativo specifico. Su Linux la luce non convergeva come un cuneo. Quindi, esiste un repository separato in cui saranno presenti diverse porte di diramazione per diversi sistemi operativi. Chi ne ha bisogno può clonare la porta corrispondente e farne quello che vuole (nei limiti della licenza, ovviamente). Bene, se qualcuno non ne ha bisogno, allora non è un mio problema. A questo punto, propongo di considerare risolta la questione della “promozione nel kernel principale di Linux”.
Le pubblicazioni sull'architettura FS sono rilevanti, ma finora ho trovato il tempo solo per i miei nuovi risultati, che considero una priorità più alta. Un'altra cosa è che sono un matematico e in matematica ogni pubblicazione è una sintesi di teoremi e delle loro dimostrazioni. Pubblicare qualcosa senza prove è segno di cattivo gusto. Se provo o confuto completamente qualsiasi affermazione sull'architettura del FS, il risultato saranno tali pile che sarà abbastanza difficile da superare. Chi ne ha bisogno? Questo è probabilmente il motivo per cui tutto continua a rimanere nella sua vecchia forma: il codice sorgente e i relativi commenti.
Cosa c'è di nuovo in Reiser4 negli ultimi anni?
La stabilità tanto attesa si è finalmente materializzata. Uno degli ultimi ad apparire è stato un bug che portava a directory “non cancellabili”. La difficoltà era che appariva solo sullo sfondo delle collisioni degli hash dei nomi e con una determinata posizione dei record di directory in un nodo dell'albero. Tuttavia, non posso ancora consigliare Reiser4 per la produzione: per questo è necessario lavorare con l'interazione attiva con gli amministratori del sistema di produzione.
Alla fine siamo riusciti a realizzare la nostra idea di lunga data: diversi modelli di transazione. In precedenza, Reiser4 eseguiva solo un modello Macdonald-Reiser hardcoded. Ciò ha creato problemi di progettazione. In particolare, le istantanee non sono possibili in un modello transazionale di questo tipo: verranno danneggiate da un componente atomico chiamato “OVERWRITE SET”. Reiser4 attualmente supporta tre modelli di transazione. In uno di essi (Write-Anywhere), il componente atomico OVERWRITE SET include solo pagine di sistema (immagini di bitmap del disco, ecc.), che non possono essere “fotografate” (il problema dell'uovo e della gallina).
Quindi le immagini possono ora essere realizzate nel miglior modo possibile. In un altro modello transazionale, tutte le pagine modificate vanno solo al OVERWRITE SET (ovvero, è essenzialmente puro journaling). Questo modello è per coloro che si sono lamentati della rapida frammentazione delle partizioni Reiser4. Ora in questo modello la tua partizione non verrà frammentata più velocemente che con ReiserFS (v3). Tutti e tre i modelli esistenti, con alcune riserve, garantiscono l'atomicità delle operazioni, ma possono essere utili anche modelli con perdita di atomicità e che preservino solo l'integrità della sezione. Tali modelli possono essere utili per tutti i tipi di applicazioni (database, ecc.) che hanno già assunto alcune di queste funzioni. È molto semplice aggiungere questi modelli a Reiser4, ma non l'ho fatto, perché nessuno me lo ha chiesto e personalmente non ne ho bisogno.
Sono comparsi i checksum dei metadati e recentemente li ho integrati con specchi “economici” (materiale ancora instabile). Se il checksum di un blocco fallisce, Reiser4 legge immediatamente il blocco corrispondente dal dispositivo di replica. Tieni presente che ZFS e Btrfs non possono farlo: il design non lo consente. Lì devi eseguire uno speciale processo di scansione in background chiamato “scrub” e attendere che raggiunga il blocco problematico. I programmatori chiamano figurativamente tali eventi “stampelle”.
Infine, sono apparsi volumi logici eterogenei, che offrono tutto ciò che ZFS, Btrfs, block layer e anche le combinazioni FS+LVM in linea di principio non possono fornire: ridimensionamento parallelo, allocatore di indirizzi del disco O(1), migrazione trasparente dei dati tra sottovolumi. Quest'ultimo ha anche un'interfaccia utente. Ora puoi spostare facilmente i dati più importanti sull'unità con le prestazioni più elevate del tuo volume.
Inoltre, è possibile scaricare urgentemente eventuali pagine sporche su tale unità, velocizzando così significativamente le applicazioni che spesso chiamano fsync(2). Noto che la funzionalità del livello di blocco, chiamata bcache, non fornisce affatto tale libertà di azione. Nuovi volumi logici si basano sui miei algoritmi (esistono brevetti corrispondenti). Il software è già abbastanza stabile, è del tutto possibile provarlo, misurare le prestazioni, ecc. L'unico inconveniente è che per ora è necessario aggiornare manualmente la configurazione del volume e memorizzarla da qualche parte.
Finora sono riuscito a realizzare le mie idee al 10%, ma sono riuscito in quella che consideravo la cosa più difficile: collegare i volumi logici con una procedura flash che esegue tutte le azioni differite in reiser4. Tutto questo è ancora nel ramo sperimentale “format41”.
Reiser4 supera xfstests?
Almeno così è stato per me quando stavo preparando l'ultima versione.
In linea di principio è possibile rendere Reiser4 un FS di rete (cluster) utilizzando i plugin?
È possibile e perfino necessario! Se crei un file di rete basato su un file system locale opportunamente progettato, il risultato sarà davvero impressionante! Nei moderni FS di rete, non sono soddisfatto della presenza di un livello di archiviazione backend, che viene implementato utilizzando qualsiasi FS locale. L'esistenza di questo livello è del tutto ingiustificata. Il FS di rete deve interagire direttamente con il livello di blocco e non chiedere al FS locale di creare altri file di servizio!
In generale, la divisione dei file system in locale e di rete viene dal male. È nato dall’imperfezione degli algoritmi utilizzati trent’anni fa e al posto dei quali non è stato ancora proposto nulla. Questo è anche il motivo della comparsa di una massa di componenti software non necessari (servizi vari, ecc.). In senso buono, dovrebbe esserci un solo FS sotto forma di modulo kernel e un insieme di utilità utente installate su ciascuna macchina: un nodo cluster. Questo FS è sia locale che di rete. E niente di più!
Se non funziona nulla con Reiser4 su Linux, vorrei offrire un FS per FreeBSD (citazione da una precedente intervista: “...FreeBSD... ha radici accademiche... E questo significa che con un alto grado di probabilità noi troverà un linguaggio comune con gli sviluppatori”) ?
Quindi, come abbiamo appena scoperto, tutto ha già funzionato perfettamente con Linux: esiste un port Reiser4 funzionante separato sotto forma di ramo master del nostro repository. Non mi sono dimenticato di FreeBSD! Offerta! Sono pronto a lavorare a stretto contatto con coloro che conoscono bene gli interni di FreeBSD. A proposito: quello che mi piace davvero della loro comunità è che le decisioni vengono prese da un consiglio aggiornato di esperti indipendenti, che non ha nulla a che fare con l'inganno del governo di una persona permanente.
Come valuti la comunità degli utenti Linux oggi? È diventato più “pop”?
Data la natura del mio lavoro, è abbastanza difficile per me valutarlo. Per lo più gli utenti vengono da me con segnalazioni di bug e richieste di correggere la sezione. Utenti come utenti. Alcuni sono più esperti, altri meno. Tutti sono trattati allo stesso modo. Ebbene, se l'utente ignora le mie istruzioni, scusatemi: l'ordine di ignoranza verrà inserito anche da parte mia.
È possibile prevedere lo sviluppo dei file system per i prossimi cinque-dieci anni? Quali pensi siano le principali sfide che gli sviluppatori FS potrebbero dover affrontare?
Sì, non è difficile fare una previsione del genere. Da molto tempo non c'è più stato lo sviluppo di file system nell'upstream. Viene creata solo l'apparenza di ciò. Gli sviluppatori di file system locali hanno riscontrato problemi associati a una progettazione scadente. Qui è necessario fare un avvertimento. Non considero sviluppo e sviluppo il cosiddetto “storage”, il “licking” e il porting del codice. E non classifico come sviluppo l’equivoco denominato “Btrfs” per le ragioni che ho già spiegato.
Ogni patch non fa altro che peggiorare i problemi. BENE. e ci sono sempre diversi tipi di “evangelisti” per i quali “tutto funziona”. Fondamentalmente si tratta di scolari e studenti che saltano le lezioni. Immagina: a lui funziona, al professore no. Che scarica di adrenalina è questa! Dal mio punto di vista, il danno maggiore è causato dagli “artigiani” che si sono affrettati ad “avvitare” con entusiasmo le meravigliose funzionalità di Btrfs su tutti i tipi di livelli come systemd, docker, ecc. - questo assomiglia già alle metastasi.
Proviamo ora a fare una previsione per cinque-dieci anni. Ho già brevemente elencato cosa faremo in Reiser4. La sfida principale per gli sviluppatori FS locali a monte sarà (sì, lo è già diventata) l'incapacità di svolgere un lavoro dignitoso per uno stipendio. Senza alcuna idea nel campo dell'archiviazione dei dati, continueranno a provare a patchare questi sfortunati VFS, XFS ed ext4. In questo contesto, la situazione con VFS sembra particolarmente comica, ricordando la frenetica modernizzazione di un ristorante in cui non ci sono chef e non sono attesi chef.
Ora il codice VFS, senza alcuna condizione, blocca più pagine di memoria contemporaneamente e invita il FS sottostante a operare su di esse. Questo è stato introdotto per migliorare le prestazioni di Ext4 nelle operazioni di eliminazione, ma come è facile capire, tale blocco simultaneo è completamente incompatibile con i modelli di transazione avanzati. Cioè, non sarai in grado di aggiungere semplicemente il supporto per alcuni file system intelligenti nel kernel. Non so quale sia la situazione in altre aree di Linux, ma per quanto riguarda i file system, è improbabile che qualsiasi sviluppo qui sia compatibile con la politica perseguita nella pratica da Torvalds (i progetti accademici vengono eliminati e i truffatori che non ho idea di cosa sia un B-tree, vengono emessi infiniti crediti di fiducia). Pertanto, è stato stabilito un percorso per un lento decadimento. Naturalmente cercheranno con tutte le loro forze di spacciarlo per “sviluppo”.
Inoltre, i "custodi" dei file system, rendendosi conto che non si può guadagnare molto solo con lo "storage", si cimenteranno in un'attività più redditizia. Questi sono, di regola, file system distribuiti e virtualizzazione. Forse porteranno l’elegante ZFS da qualche altra parte dove ancora non esiste. Ma, come tutte le FS a monte, assomiglia a un albero di Capodanno: se puoi appendere altre piccole cose sopra, non puoi andare più in profondità. Ammetto che è possibile costruire un sistema aziendale serio basato su ZFS, ma poiché ora stiamo discutendo del futuro, posso solo affermare con tristezza che ZFS è senza speranza in questo senso: con i loro dispositivi virtuali, i ragazzi hanno tolto l'ossigeno per se stessi e per le generazioni future per un ulteriore sviluppo. ZFS è una cosa del passato. E ext4 e XFS non sono nemmeno l'altro ieri.
Vale la pena menzionare separatamente il concetto sensazionale di "file system Linux di prossima generazione". Si tratta di un progetto completamente politico e di marketing creato per l'opportunità, per così dire, di "fissare il futuro dei file system" in Linux dietro caratteri specifici. Il fatto è che Linux era “solo per divertimento”. Ma ora è soprattutto una macchina per fare soldi. Sono fatti su tutto il possibile. Ad esempio, è molto difficile creare un buon prodotto software, ma gli "sviluppatori" intelligenti hanno capito da tempo che non è necessario sforzarsi affatto: puoi vendere con successo software inesistente che è stato annunciato e promosso a tutti i tipi di pubblico eventi: la cosa principale è che le diapositive della presentazione contengano più "funzionalità".
I file system sono perfetti per questo, perché puoi tranquillamente contrattare per dieci anni sul risultato. Ebbene, se qualcuno in seguito si lamenta della mancanza di questo stesso risultato, semplicemente non capisce nulla di file system! Ricorda una piramide finanziaria: in cima ci sono gli avventurieri che hanno iniziato questo pasticcio, e quei pochi che sono stati “fortunati”: hanno “ritirato i dividendi”, cioè hanno ricevuto soldi per lo sviluppo, hanno ottenuto un lavoro ben pagato come manager, "si sono presentati" alle conferenze, ecc.
Poi vengono quelli che sono “sfortunati”: conteranno le perdite, affronteranno le conseguenze dell’implementazione di un prodotto software inutilizzabile nella produzione, “ecc. Ce ne sono molti altri. Ebbene, alla base della piramide c'è un'enorme massa di sviluppatori che “segano” codice inutile. Sono loro i maggiori perdenti, perché il tempo sprecato non può essere restituito. Tali piramidi sono estremamente utili a Torvalds e ai suoi associati. E più ci sono queste piramidi, meglio è per loro. Per alimentare tali piramidi, qualsiasi cosa può essere introdotta nel nucleo. Naturalmente in pubblico si dice il contrario. Ma non giudico dalle parole ma dai fatti.
Quindi, “il futuro dei file system in Linux” è ancora un altro software altamente pubblicizzato, ma difficilmente utilizzabile. Dopo Btrfs, con un'alta probabilità, il posto di tale "futuro" sarà preso da Bcachefs, che è un altro tentativo di attraversare il livello di blocchi di Linux con un file system (un cattivo esempio è contagioso). E ciò che è tipico: ci sono gli stessi problemi di Btrfs. Lo sospettavo da molto tempo, e poi in qualche modo non ho potuto resistere e ho guardato il codice: è vero!
Gli autori di Bcachefs e Btrfs, durante la creazione del loro FS, hanno utilizzato attivamente fonti di altre persone, capendone poco. La situazione ricorda molto il gioco per bambini “telefono rotto”. E posso immaginare approssimativamente come questo codice verrà incluso nel kernel. In realtà nessuno vedrà i “rastrelli” (tutti li calpesteranno più tardi). Dopo numerosi cavilli sullo stile del codice, accuse di violazioni inesistenti, ecc., si giungerà alla conclusione sulla "lealtà" dell'autore, su quanto bene "interagisce" con gli altri sviluppatori e con che successo tutto ciò può poi essere venduto alle multinazionali.
Il risultato finale non interesserà a nessuno. Vent'anni fa forse mi avrebbe interessato, ma ora le domande si pongono diversamente: sarà possibile promuoverlo in modo che entro i prossimi dieci anni certe persone trovino lavoro. E, ahimè, non è consuetudine interrogarsi sul risultato finale.
In generale, sconsiglio vivamente di iniziare a reinventare il file system da zero. Perché anche importanti investimenti finanziari non basteranno per ottenere qualcosa di competitivo tra dieci anni. Ovviamente sto parlando di progetti seri e non di quelli che intendono essere "inseriti" nel kernel. Quindi, un modo più efficace per esprimerti è unirti agli sviluppi reali, come noi. Questo, ovviamente, non è facile da realizzare, ma questo è il caso di qualsiasi progetto di alto livello.
Innanzitutto, dovrai superare autonomamente il problema che offrirò. Dopodiché, convinto della serietà delle tue intenzioni, comincerò ad aiutarti. Tradizionalmente utilizziamo solo i nostri sviluppi. Le eccezioni sono gli algoritmi di compressione e alcune funzioni hash. Non mandiamo gli sviluppatori in viaggio per partecipare a conferenze, e poi non ci sediamo e combiniamo le idee di altre persone (“forse cosa succederà”), come è consuetudine nella maggior parte delle startup.
Sviluppiamo noi stessi tutti gli algoritmi. Attualmente sono interessato agli aspetti algebrici e combinatori della scienza dell'archiviazione dei dati. In particolare, campi finiti, asintotici, dimostrazione delle disuguaglianze. C'è lavoro anche per i programmatori ordinari, ma devo avvisarti subito: tutti i suggerimenti di "guardare un altro FS e fare lo stesso" vengono ignorati. Qui arriveranno anche le patch mirate ad una più stretta integrazione con Linux tramite VFS.
Quindi, non abbiamo un rastrello, ma sappiamo dove dobbiamo muoverci e abbiamo fiducia che questa direzione sia quella giusta. Questa comprensione non è arrivata sotto forma di manna dal cielo. Lascia che ti ricordi che abbiamo alle spalle 29 anni di esperienza di sviluppo, due file system scritti da zero. E lo stesso numero di utilità di recupero dati. E questo è tanto!
Fonte: opennet.ru