Parliamo spesso di filesystem, ultimamente in particolare di ZFS, ma quelli disponibili con il Kernel Linux sono davvero molti. Ad esempio ReiserFS.
La prima versione pubblicata risale al 2001, col nome ReiserFS, e viene introdotto nel kernel 2.4 piuttosto rapidamente. Prende il nome dal suo creatore Hans Reiser.
Essendo la versione 3.6, spesso ci si riferisce ad essa come Reiser3.

Nel 2004 è rilasciata la versione 4, e il nome ufficiale diventa Reiser4. Pur essendo tanto apprezzato da diventare il filesystem di default di SuSE, questa versione non riesce ad entrare nel Kernel standard, rimanendo un modulo out-of-tree. Quando poi, nel 2008, il creatore viene arrestato e condannato per l’omicidio della moglie, sembra la sua fine.
Ma in soccorso arriva Edward Shishkin, un dipendente di Namesys, la società fondata da Reiser per lo sviluppo del filesystem. Shishkin prende in mano lo sviluppo e il mantenimento del codice e riesce a creare una piccola comunità. Namesys, nel frattempo, viene finanziata direttamente dal DARPA americano, l’agenzia per la ricerca avanzata della difesa.

L’ultimo annuncio è proprio del trentuno dicembre 2019: un nuovo formato di filesystem, che si porta dietro anche una nuova versione, Reiser5.
L’apertura è tutta per quello che viene definito un nuovo livello qualitativo per i filesystem:

I am happy to announce a brand new method of aggregation of block
devices into logical volumes on a local machine. I believe, it is a
qualitatively new level in file systems (and operating systems)
development – local volumes with parallel scaling out.

Sono felice di annunciare un metodo nuovo di zecca di aggregazione dei dispositivi a blocchi in volumi logici su una macchina locale. Credo essere un nuovo livello qualitativo nello sviluppo dei file system (e dei sistemi operativi) – volumi locali con crescita parallela.

Parole piuttosto roboanti, a dire il vero. E l’annuncio, in realtà, è tutto per questa feauture: parallel scaling out.
L’obiettivo è aggregare più dischi fisici in un unico disco virtuale, aggregando anche prestazioni e spazio. Secondo Shishkin, le alternative attuali (come RAID-0, o anche ZFS) soffrono di limitazioni (in particolare di prestazioni) troppo grosse, dovute al design usato.
Segue immediatamente dopo una lunga spiegazione tecnica, che vi esponiamo.

La tecnica attuale prevede – di norma – l’uso di un software per mostrare al sistema operativo un dispositivo a blocchi virtuale su cui lavorare come fosse quello reale: quando il sistema operativo manderà un comando al dispositivo virtuale, lo strato software si preoccuperà di indirizzare i comandi ai vari dischi reali che eseguiranno il lavoro. Il filesystem è creato quindi su un disco virtuale.

Se prendiamo a riferimento RAID-0, la limitazione principale sta nel fatto che il dispositivo con minori prestazioni detta le prestazioni massime di tutti i dischi coinvolti: visto che i comandi sono distribuiti a tutti i dischi, tutti devono aspettare il più lento. Allo stesso modo, per lo spazio a disposizione, è il disco più piccolo a dettare la massima dimensione usabile, per essere sicuri che il blocco su cui un comando deve lavorare esista.
Prendendo a riferimento LVM, possiamo adottare un’implementazione più semplice, quella lineare: in questo caso viene usato un disco alla volta, finché non è pieno, per poi lavorare al successivo. Sebbene sia possibile usare tutto lo spazio dei dischi fisici, anche se di dimensioni diverse, di fatto viene usato un solo disco alla volta (specialmente in scrittura), senza alcun aumento di prestazioni all’aumentare dei dischi coinvolti.
ZFS e BTRFS permettono l’uso a livello di filesystem di più dischi, ma di fatto implementano al loro interno le stesse logiche nella gestione dei blocchi.

Shishkin crede che sia questo approccio ad essere sbagliato, e che si debba invece prendere esempio dai filesystem di rete: cita LUSTRE e GPFS di IBM, ma un’analogia migliore potrebbe essere GlusterFS (ora di RedHat). In questi filesystem ogni dispositivo (brick) è formattato come fosse un disco normale, con un suo filesystem, ed è lo strato software soprastante (il filesystem di rete) a presentare i singoli brick come un unico disco e a gestire il flusso di informazioni.
In questa maniera, invece di dover gestire i blocchi di un disco immenso, il compito è la gestione di più file su più dischi: lavoro più semplice e che può essere svolto in parallelo.
Inoltre, invece di dover dividere i comandi (e i dati) allo stesso modo tra i dischi, questi potranno essere distribuiti tenendo conto sia della velocità del singolo disco (dando più comandi a dischi più veloci) che della sua dimensione (memorizzando più dati nei dischi più grandi). Processi in background si occuperanno poi di mantenere il tutto in ordine, spostando i dati da un disco ad un altro per mantenere un’occupazione (in percentuale) simile tra i dischi.

L’implementazione reale è un poco più complessa (e, per esempio, prevede un disco dedicato ai metadati di tutto il set): casomai foste interessati, l’annuncio fornisce una panoramica piuttosto esaustiva, mentre è già (quasi) pronta la documentazione per le operazioni di gestione dei volumi.

L’idea alla base di questo annuncio sembra interessante, e pare anche una evoluzione di quanto già presentato nel 2016 per il mirroring. Che, però, è rimasto allo stadio di annuncio e prove tecniche: tutt’ora la pagina di documentazione ufficiale è piena di TBD (To Be Done), ovvero cose ancora da fare. Vedremo quando l’implementazione del parallel scale out sarà davvero completato.

L’introduzione di una tale novità giustifica il cambio di versione, mentre mantenere il nome Reiser pare meno condivisibile: rimane il nome di un assassino reo confesso, e a molti questo potrebbe dare parecchio fastidio. Tanto che qualcuno crede sia il vero motivo per cui ancora non faccia parte del Kernel, sebbene ci siano ragioni più tecniche che risalgono al 2006…

Voi siete pronti a provarlo? E vi sta bene il nome, o (anche) per questo lo eviterete?

Marco Bonfiglio

Ho coltivato la mia passione per l’informatica fin da bambino, coi primi programmi BASIC. In età adulta mi sono avvicinato a Linux ed alla programmazione C, per poi interessarmi di reti. Infine, il mio hobby è diventato anche il mio lavoro.
Per me il modo migliore di imparare è fare, e per questo devo utilizzare le tecnologie che ritengo interessanti; a questo scopo, il mondo opensource offre gli strumenti perfetti.