Nelle puntate precedenti abbiamo esaminato filesystem non tradizionali come tmpfs e devfs. Ora è tempo di tornare ai filesystem studiati per essere utilizzati su hard-disk e cominceremo occupandoci di ext3. Il filesystem ext3, progettato dal Dr. Stephen Tweedie, è stato costruito a partire dalla struttura di un filesystem già esistente: ext2; infatti ext3 è molto simile ad ext2 ad eccezioni di una piccola (ma importante) differenza: ext3 supporta il journaling. Proprio per questa piccola implementazione penso che troverete che ext3 ha molte sorprendenti ed intriganti possibilità. In questo articolo farò in modo di darvi una buona conoscenza delle possibilità di ext3 confrontato con gli altri filesystem journaling che sono attualmente disponibili. Nel prossimo articolo vedremo come impostare la propria macchina per far funzionare ext3.

Allora, com'è ext3 se confrontato con ReiserFS? Nel precedente articolo ho spiegato che ReiserFS è molto indicato per gestire file di piccole dimensioni (al di sotto dei 4K), ed in certe situazioni la gestione dei piccoli file risulta essere da dieci a quindici volte più performante con ReiserFS rispetto a ext2 ed ext3. Ma come ReiserFS presenta molti punti di forza, esso è meno performante sotto altri punti di vista. Nell'ultima implementazione di ReiserFS (la versione 3.6), alcuni schemi di accesso ai file possono determinare dei veri e propri crolli di prestazioni rispetto a ext2 ed ext3, in particolare la lettura di directory di grandi dimensioni di posta elettronica. Inoltre ReiserFS non ha una buona registrazione di traccia di NFS e le prestazioni in presenza di file frammentati sono ridotte. Dall'altro lato ext3 è un filesystem ben costruito. È molto simile ad ext2; non raggiungerà mai le performance ultra-veloci di ReiserFS con i piccoli file, ma nemmeno soffrirà di imprevedibili anomalie di funzionamento o grande variabilità nelle prestazioni.

Una delle belle cose di ext3 è che, essendo basato sul codice di ext2, l'organizzazione dei dati di ext2 e di ext3 sul disco è identica; questo significa che se si smonta un filesystem ext3 in modo pulito, questo può venir rimontato come un filesystem ext2 senza alcun problema. E non è tutto. Grazie al fatto che ext2 ed ext3 usano metadata identici, è possibile eseguire l'upgrade di un filesystem ext2 ad ext3. Certo, hai letto bene. Aggiornando qualche utility del sistema, installando un kernel 2.4 e digitando un comando tune2fs per ogni filesystem da aggiornare, puoi convertire il tuo server ext2 in una macchina che sfrutta i vantaggi del journaling di ext3. Puoi farlo addirittura mantenendo montati i filesystem ext2. La conversione dall'uno all'altro è sicura, reversibile e facilissima, inoltre, al contrario di quanto succederebbe per passare a XFS, JFS o ReiserFS, non c'è bisogno di fare il backup dei dati e ricreare i filesystem da zero. Ora, per un istante, pensa alle migliaia di server di produzione che utilizzano ext2 e a cui basterebbero un paio di minuti per effettuare un upgrade ad ext3; ora hai un'idea dell'importanza che ricopre ext3 nella comunità di Linux.

Se dovessi descrivere ext3 con un'unica parola, userei "comodo". È estremamente facile fare l'upgrade ad ext3 di un sistema che utilizza ext2, e dopo averlo fatto non ci si imbatterà in alcuna sorpresa per quanto riguarda le prestazioni. E c'è anche un altro aspetto che rende ext3 molto comodo: questo filesystem è uno dei più affidabili filesystem journaled disponibili per Linux, come mi accingo a spiegarvi.

Oltre ad essere compatibile con ext2, ext3 eredita altri vantaggi dall'utilizzo della stessa struttura dei metadata di ext2. Infatti gli utilizzatori di ext3 possono utilizzare il tool fsck che risulta essere molto stabile e affidabile. Un'obiezione può essere che il principale motivo per cui si usa un filesystem journaled è quello di evitare di fare il check completo del filesystem con fsck; però se per qualche motivo ci si dovesse imbattere in metadata corrotti, a causa di un'anomalia del kernel o per un hard disk malfunzionante o per qualsiasi altra cosa, di sicuro apprezzerai che ext3 può utilizzare il tool fsck di ext2. Al contrario il tool fsck di ReiserFS è appena nato e la riparazione di metadata corrotti, nel momento del bisogno, può risultare un processo difficile e pericoloso.

È interessante vedere come il modo di gestire il journaling di ext3 è molto diverso da quello di ReiserFS e di altri filesystem journaled. Con ReiserFS, XFS e JFS il driver del filesystem registra i metadata, ma non si preoccupa di prendere delle misure di sicurezza per quanto riguarda la registrazione dei dati veri e propri sul disco. Con questo tipo di journaling (metadata-only) il metadata del filesystem è veramente molto robusto e probabilmente non avrai mai bisogno di eseguire un check completo del filesystem con fsck. D'altro canto dei riavvii improvvisi e crash del sistema possono portare ad una corruzione significativa dei dati che si stavano modificando. Ext3 usa un paio di soluzioni innovative per raggirare questo problema. Le vedremo subito.

Ma prima è importante capire come esattamente il journaling di tipo metadata-only prima o poi distruggerà la tua vita. Facciamo un esempio: supponiamo che tu stia modificando il file /tmp/miofile.txt e ad un certo punto la macchina vada in crash costringendoti a riavviarla brutalmente. Se stavi usando un filesystem con journaling di tipo metadata-only come ReiserFS, XFS e JFS i metadata potranno essere riparati facilmente, grazie al journal, e non ci sarà bisogno di eseguire un estenuante check con fsck.

Però c'è una possibilità non nulla che quando andrai ad aprire il file /tmp/miofile.txt con il tuo editor di testi preferito, nel file non solo potrebbero mancare le ultime modifiche, ma il file potrebbe contenere anche un po' di spazzatura oppure potrebbe risultare addirittura completamente inaccessibile. Non voglio dire che questo accade ogni volta, ma potrebbe succedere e spesso accade.

E ciò accade per questo motivo. I filesystem journaled tipici come ReiserFS, XFS e JFS danno moltissima importanza ai metadata, ma non fanno sufficiente attenzione ai dati. Nell'esempio fatto in cui i dati risultavano effettivamente corrotti, il driver del filesystem stava per modificare parecchi blocchi del filesystem. Il driver aggiornò i relativi metadata, ma non ebbe il tempo di trasferire i dati dalla cache in memoria ai blocchi fisici del disco. Così quando si è provato ad aprire il file /tmp/miofile.txt in un editor, una parte del file conteneva spazzatura (blocchi di dati che non sono stati registrati prima del crash).

Ora che conosciamo meglio il problema, vediamo come ext3 implementa il journaling. In ext3 il codice del journaling usa un'API particolare chiamata Journaling Block Device layer (JBD). Il JBD è stato pensato al fine preciso di poter implementare un journal su qualsiasi tipo di supporto a blocchi. Il journaling di ext3 è stato costruito portando l'API di JBD al suo interno. Facciamo un esempio del funzionamento: il codice del filesystem di ext3 informa il JBD delle modifiche che sta per effettuare e chiede al JBD il permesso prima di modificare qualsiasi dato sul disco. In questo modo al JBD è affidato il compito di gestire il journaling per conto del driver del filesystem di ext3. È proprio un bel meccanismo e, grazie al fatto che il JBD è sviluppato separatamente come un'entità generica, esso potrà essere usato nel futuro per implementare il journaling in altri filesystem.

Ci sono poi un paio di cose molto curate del journal di ext3 gestito dal JBD. Per prima cosa il journal di ext3 è registrato in un inode (che sostanzialmente è un file). A seconda di come si attiva il filesystem ext3 nel proprio sistema si sarà o meno in grado di vedere questo file che viene posto in /.journal. Di sicuro, salvando il journal in un inode, ext3 è in grado di implementare il journal nel filesystem senza il bisogno di aggiungere estensioni alla struttura dei metadata che potrebbero quindi portare ad incompatibilità con ext2. Questo è il motivo fondamentale per cui ext3 mantiene la compatibilità con ext2 e di conseguenza con il driver del filesystem di ext2.

Non desta meraviglia che ci siano molti modi diversi per implementare il journal in un filesystem. Per esempio lo sviluppatore di un filesystem può programmare un journal che registra la serie di byte che verranno modificati nel filesystem vero e proprio. Il vantaggio di questo approccio è che il journal sarà in grado di salvare molte piccole modifiche del filesystem in modo molto efficiente, poiché si preoccuperà di registrare solo i byte che verranno modificati e nessun'altra informazione superflua.

Il JBD ha un approccio diverso e per certi versi migliore. Invece di registrare la serie di byte che dovranno essere modificati, JBD salva gli interi blocchi del filesystem che sono interessati dall'operazione sul disco. Il driver del filesystem di ext3 usa anch'esso questo approccio e salva la copia completa dei blocchi modificati (di 1K, 2K o 4K) nella memoria per tenere traccia delle operazioni di input/output in esecuzione. Al primo sguardo questo può sembrare un po' uno spreco di risorse. Dopotutto nei blocchi completi sono presenti i dati modificati, ma possono esserci anche dati non modificati effettivamente (sul disco).

L'approccio usato dal JBD è chiamato journaling fisico, che significa che JBD usa i blocchi fisici completi, uguali alla struttura sottostante, per implementare il journal. Al contrario quando il journal salva solo la serie di byte modificati, anziché i blocchi interi, si parla di journaling logico e questo è il metodo usato da XFS. Poiché ext3 utilizza il journaling fisico, un journal di ext3 avrà bisogno di uno spazio maggiore su disco rispetto al journal, per esempio, di XFS. Ma il fatto che ext3 utilizzi blocchi completi sia al suo interno che per il journal ha fatto si che la struttura ed il codice non raggiungesse la complessità che sarebbe stata invece necessaria per implementare un journaling logico. Oltre a questo, l'uso di blocchi interi permette ad ext3 di ottenere qualche ulteriore ottimizzazione, come il riunire più operazioni di input/output pendenti in un singolo blocco all'interno della stessa struttura dati residente in memoria. Questo a sua volta permette ad ext3 di scrivere più cambiamenti del disco in una sola operazione di scrittura, anziché in molte. Inoltre, poiché il blocco di dati considerato è salvato in memoria, non sono necessarie o sono addirittura assenti le operazioni da effettuare sui dati in memoria prima della scrittura sul disco, riducendo considerevolmente l'utilizzo della CPU.

Vediamo infine come il filesystem ext3 gestisce efficacemente sia i metadata che i dati del journal, raggirando il problema della corruzione dei dati che ho descritto all'inizio dell'articolo. Infatti, a dire il vero, ext3 utilizza due modi per garantire l'integrità dei dati e metadata.

Originariamente ext3 fu concepito per eseguire un journaling completo di dati e metadata. In questo metodo (chiamato "data=journal" mode), il JBD registra tutti i cambiamenti fatti al filesystem, sia che si tratti dei dati che dei metadata. Poiché sia i dati che i metadata sono registrati nel journal, JBD può usare il journal per riportare ad uno stato consistente sia i metadata che i dati. Il rovescio della medaglia dell'effettuare il journaling di tutti i dati è che esso può risultare lento, anche se è possibile ovviare in parte a questa diminuzione delle prestazioni impostando un journal relativamente grande.

Ultimamente è stato aggiunto ad ext3 un nuovo metodo di journaling che assicura i vantaggi del journaling completo, ma senza penalizzare fortemente le prestazioni. Con questo nuovo metodo vengo registrati solo i metadata. Tuttavia il driver del filesystem di ext3 tiene traccia di ogni blocco di dati corrispondente ad ogni aggiornamento dei metadata, ragruppandoli in un'unica entità chiamata transizione. Quando una transizione è applicata al filesystem vero e proprio, i blocchi dei dati sono per prima cosa scritti sul disco. Una volta che i dati sono stati scritti sul disco i cambiamenti apportati ai metadata sono scritti sul journal. Usando questa tecnica (chiamata "data=ordered" mode) ext3 può assicurare la consistenza dei dati e metadata anche se vengono registrati nel journal solo i cambiamenti effettuati ai metadata. Ext3 usa questo metodo di default.

Ultimamente molte persone stanno cercando di capire quale sia il miglior filesystem journaling di Linux. In verità non c'è un unico filesystem giusto per tutte gli utilizzi; ogniuno ha i suoi punti di forza. Questo è uno dei vantaggi nel fatto che ci siano così tanti filesystem di nuova generazione in Linux tra i quali scegliere. Quindi, anziché prendere a caso un filesystem considerandolo il migliore ed usarlo per tutti gli impieghi concepibili, sarebbe meglio conoscere e capire i punti di forza e di debolezza di ogni filesystem in modo da poter prendere una decisione ponderata su quale usare.

Ext3 ha molti punti di forza. È stato costruito per essere estremamente facile da usare. È basato sul codice molto stabile di ext2 ed eredita da esso un fantastico strumento di chek del filesystem (fsck). E le proprietà del journaling di ext3 sono state pensate in particolare per assicurare l'integrità sia dei dati che dei metadata. Dopotutto ext3 risulta essere veramente un bel filesystem, ed un degno successore dell'ormai venerabile ext2. Ti invito a prendere visione del mio prossimo articolo, dove spiegherò come impostare e preparare la tua macchina all'utilizzo di ext3. Intanto potresti voler dare un'occhiata alle risorse presenti nei link che seguono.

Puoi leggere un libretto del Dr. Stephen Tweedie che tratta di ext3 e fa una presentazione dei filesystem journaling. Fu presentato all'Ottawa Linux Symposium nel Luglio del 2000.

Per sapere qualcosa di più sull'uso di ext3 con un kernel 2.4 vedi la pagina ext3 per 2.4 di Andrew Morton. Andrew Morton è il responsabile del porting di ext3 sul kernel 2.4 ed ha contribuito in modo insostituibile alla scrittura di questo articolo. Se non riesci ad attendere l'uscita del mio prossimo articolo, Andrew ha scritto una bellissima pagina su ext3 ed il suo uso con il kernel 2.4 che ti mostrerà come configurare ed utilizzare ext3 sulla tua macchina in poco tempo.

Per tenerti aggiornato sui nuovi sviluppi di ext3 puoi visitare l'archivio della mailing list degli utenti di ext3. E puoi iscriverti qui.

Dai uno sguardo al tutorial di Daniel Robbins sulle basi di JFS su developerWorks.

Naviga qui su developerWorks per maggiori risorse su Linux.

Naviga qui su developerWorks per maggiori informazioni sull'Open Source.

Daniel Robbins abita ad Albuquerque in New Messico, è il Presidente/CEO di Gentoo Technologies, Inc., l'ideatore di Gentoo Linux, un sistema Linux avanzato per PC, ed il sistema Portage, un sistema di port per Linux di nuova generazione. Ha contribuito come autore ai libri della Macmillan: Caldera OpenLinux Unleashed, SuSE Linux Unleashed e Samba Unleashed. Daniel è stato coinvolto nel mondo dei computer in un certo qual modo dalla seconda elementare quando per la prima volta si imbatté nel linguaggio di programmazione Logo ed assunse una dose potenzialmente pericolosa di Pac Man. Questo probabilmente spiega come mai è stato impiegato come Lead Graphic Artist alla SONY Electronic Publishing/Psygnosis. A Daniel piace un sacco stare con sua moglie, Mary, e la loro figliola, Hadassah. Puoi metterti in contatto con Daniel all'indirizzo drobbins@gentoo.org.