I nuovi file system per GNU/Linux: NiLFS(2) (parte prima)

GNU/Linux ovvero il sistema operativo più innovativo per quel che riguarda file system

Da sempre il sistema operativo open per eccellenza è stato un laboratorio di sperimentazioni da parte di tutti i professionisti ed appassionati che lavorano con esso.

I file system sono una parte importante di un OS e spesso pesano in modo importante sulle prestazioni generali del sistema, GNU/Linux da parte sua non ha avuto mai grandi carenze da questo punto di vista ha anzi innovato molto il settore attraverso la famiglia di file systema ext ormai giunta alla versione 4.

Velocità, ottimizzazione e sicurezza sono i criteri che hanno da sempre contraddistinto questa famiglia di file di sistema anche se nella versione 4 piccole incomprensioni hanno lasciato pensare al peggio.

Se ad andiamo ad analizzare questo settore troveremo che da circa un decennio non si registrano grandi rivoluzioni concettuali all’interno di questo importante settore informatico, tutte le migliorie che abbiamo registrato fino ad ora sono implementazioni migliorate di idee che ormai hanno la loro veneranda età considerando la rapida evoluzione del mercato.

La notizia di un nuovo file system per il pinguino porta subito una certa emozione, badate bene non sto parlando di una nuova versione o release di un sistema già esistente ma proprio di un nuovo prodotto nuovo di zecca che deve ancora vedere la luce.

Stiamo parlando di un log-structured file system, l’intuizione per questo sistema risale al 1988 ad opera di John Ousterhout e Fred Douglis successivamente la prima implementazione si è potuta osservare all’interno del sistema operativo Sprite nato nel 1992.

Un log-structured file system è in grado di vedere il file system come un log circolare dove i dati ed i metadati vengono scritti alla testa di un file di log e lo spazio necessario alla scrittura dei nuovi dati viene di volta in volta recuperato dalla coda stessa del file.

Visto che il concetto espresso è di difficile interpretazione senza supporto video mettiamo una bella immagine in grado di fare chiarezza:

il sistema prevede quindi che alcuni dati possano essere presenti più volte all’interno del log ma in questo caso solo i dati in testa, quindi i più recenti, saranno attivi.

Si possono già intuire alcuni vantaggi di questa architettura:

1) maggiore facilità di recupero dei dati in caso di crash di sistema

2) maggiore velocità a causa della scrittura in sequenza delle informazioni

Sistema di storage Object-based

Un sistema di memorizzazione tradizionale fa uso di porzione fisse di dati, predefinite dall’utente o autonomamente scelte dall’OS, per immagazzinare i dati in blocchi di dimensioni più o meno piccoli, ad ogni blocco, o ad ogni file nel caso del nuovo ext4, è associato un file di metadati che ne indica la posizione sul disco.

Che ne pensate di un sistema in grado di scalare la dimensione dei blocchi?

Questa in estrema sintesi la soluzione che potremmo vedere in questo nuovo file system, si può creare un sistema di gestione dei dati come se fossero oggetti che a loro volta non sono altro che una collezione di blocchi differenti riguardanti tutti lo stesso file.

E’ possibile interagire con gli oggetti in modo profondo, quindi con classici componenti OSD, o con sistemi di elevato livello come driver o altro; la novità è che mentre nel sistema tradizionale esistono protocolli che comunicano direttamente con un singolo blocco che compone un file ora è possibile comunicare direttamente con il file ed il suo metadato associato tralasciando di operare con il singolo blocco di memoria nel quale risiedono parte dei dati all’interno del disco rigido.

Anche in questo caso una immagine può schiarirci le idee:

NiLFS, questo è il nome

Belle parole e belle idee ma in fin dei conti ci sono dei primi risultati?

Ebbene si i primi esperimenti con queste tecnologie ci sono e provengono dal Giappone dove il Nippon Telegraph and Telephone (NTT) lavorano alacremente al progetto con ritmo serrato.

Il prodotto in questione è entrato nella mainline del kernel Linux ed in quella del NetBSD, ad una prima versione del 2005 ne è seguita una del 2007 e da questo anno è possibile attivare l’apposito supporto per coloro che amano operare sperimentazioni su kernel e dischi in GNU/Linux.

Una delle caratteristiche più interessanti di questo file system è la capacità di creare dei snapshot continui di se stesso e vista la sua struttura di registro con i nuovi dati in testa ed i vecchi ancora in corpo e coda vi è la possibilità di recuperare una infinità di versioni diverse del vostro file appena modificato.

La sicurezza dei dati salvati su di questo FS lascia al riparo dai classici errori dati da cadute di tensione o altri problemi che potrebbero spegnere improvvisamente la macchina lasciando cadere la testina di lettura sui piatti del vostro hdd.

Ogni snapshot viene chiamo punto di controllo e sono parte integrante del file system stesso, è possibile creare i punti in modo del tutto automatico ad ogni modifica di un file o più comodamente dietro indicazione dell’utente che può forzare il sistema a crearne uno.

Una volta creato lo snapshot è possibile far rivivere nella macchina il vecchio file system appena cambiato semplicemente montando quanto appena creato, per ora è possibile montare questi punti in sola lettura e penso che non serva avere una modifica delle vecchie “immagini” in quanto dovrebbero servire come sistemi di recupero di file.

Oltre al recupero dei file è intuibile una seconda funzione di questa meravigliosa implementazione, pensata ad una macchina che, dopo una caduta di tensione, presenta dei gravi errori all’interno del file system tali da non permettere il corretto avvio della stessa, in casi come questi sarà sufficiente far fare un passo indietro al file system per avere una macchina che si avvia correttamente e quindi perfettamente in grado di permetterci di recuperare, correggere o modificare qualsiasi impostazione errata……..sicuramente un’arma migliore rispetto al classico check del disco attraverso fsck.

Andiamo però a vedere il rovescio della medaglia, anche se il sistema di scrittura capo/coda del file system porta a benefici in termini di velocità in quanto di natura sequenziale dobbiamo ricordare come sia necessaria una raccolta dei vecchi dati di spazzatura dalla coda stessa del system.

Se questa raccolta si reputa necessaria ecco che ci possiamo imbattere in rallentamenti indesiderati di tutto il sistema, si potrebbe pensare di bypassare questa operazione ma essa si reputa necessaria per procedere alla pulizia del vecchi dati e metadati ormai obsoleti.

Nel prossimo post affronteremo una prova di carattere pratico mettendo le mani tra le poche e semplici linee di codice necessarie a capire il funzionamento di questa prossima meraviglia del pinguino.

Ciao a tutti.

P.S.: rileggendo il post ho notato come la differenza tra snapshot e punti di controllo non emerga in modo chiaro, mentre i primi sono effettuati dal sistema in modo continuo i secondi possono essere regolati secondo delle precise regole temporali.

I punti di controllo permettono anche l’avvio della macchina in caso di difficoltà cosa che invece non è in grado di fare lo snapshot il quale comunque può sempre venir convertito in punto di controllo tramite apposito comando.