In ReiserFS i dati vengono organizzati in un struttura ad albero bilanciato (ingl. B^*-balanced tree). La struttura ad albero contribuisce a sfruttare meglio la memoria del disco rigido, dato che piccoli file possono essere memorizzati nello stesso blocco, invece di essere memorizzati altrove e dover gestire il puntatore sulla localizzazione effettiva. Inoltre la memoria non viene assegnata nella misura di unità di 1 o 4 kbyte, ma esattamente nella misura richiesta. Un altro vantaggio è l'allocazione dinamica degli inode che rende i file system più flessibili rispetto ai tradizionali file system come ad esempio Ext2, dove bisogna indicare la densità degli inode al momento della generazione del file system.

Nel caso di piccoli file vi sarete accorti che sia i dati file sia le informazioni (inode) «stat_data» vengono memorizzati gli uni accanto agli altri sul disco rigido. Basta accedere una volta sola al disco per avere tutte le informazioni di cui avete bisogno.

L'uso dei journal, per ricostruire le modifiche apportate ai meta-dati, riduce i tempi di verifica anche nel caso di grandi file system ad una manciata di secondi.

ReiserFS supporta inoltre il data journaling e ed il data odered è simile a quanto illustrato nella Sezione 34.2.3, «Ext3» dedicata a Ext3. Il modo di default è data=ordered, il quale assicura l'integrità sia dei dati che dei metadata, utilizzando comunque il journaling solo per i metadata.

L'appellativo «solido come una roccia» non è dovuta al caso visto che nel corso degli anni Ext2 è stato continuamente migliorato ed ampiamente testato. Nel caso di un crollo del sistema senza un corretto smontaggio del file system, e2fsck analizza i dati del file system. I meta-dati vengono portati in una stato consistente, e file o blocchi di dati in sospeso vengono scritti in una determinata directory (chiamata lost+found). Contrariamente alla maggior parte dei journaling file system, e2fsck analizza l'intero file system e non solo i bit dei meta-dati modificati di recente. Questo richiede più tempo rispetto alla verifica dei dati protocollo di un journaling file system. A seconda del volume del file system, questo processo può durare mezz'ora o oltre. Per questo motivo Ext2 non è particolarmente adatto per server ad alta disponibilità. Dato che Ext2 comunque non deve aggiornare continuamente alcun journal e richiede una quantità notevolmente inferiore di memoria a volte risulta essere più veloce di altri file system.

Basato sulla solida base di Ext2, Ext3 divenne l'acclamato file system di prossima generazione. L'affidabilità e la stabilità vennero coniugate sapientemente con i vantaggi di un journaling file system.

Visto che Ext3 si basa sul codice di Ext2 e che appoggia sia il formato on-disk che il formato meta-dati di Ext2, gli upgrade da Ext2 verso Ext3 risultano essere facilissimi da eseguire. Si può eseguire un upgrade anche quando ad essere montati sono i file system di Ext2. Diversamente dalla migrazione verso altri journaling file system, come ReiserFS, JFS o XFS che può diventare una faccenda davvero laboriosa, (dovete fare delle copie di sicurezza di tutto il file system e successivamente ricostruirlo «ex novo»), passare a Ext3 è una questione di pochi minuti. Inoltre è molto sicuro visto che durante la ricostruzione di un completo file system spesso si possono verificare degli errori. Se si considera l'elevato numero di sistemi Ext2 che aspettano un upgrade a un journaling file system, si può facilmente intuire l'importanza di Ext3 per tanti sistemisti. Eseguire un downgrade da Ext3 a Ext2 è così facile come eseguire un upgrade. Basta smontare correttamente il file system Ext3 e montarlo in seguito come file system Ext2.

Altri journaling file system seguono l'approccio cosiddetto journaling metadata-only, cioè i vostri meta-dati rimangono in uno stato consistente, cosa che comunque non può essere garantita automaticamente per i dati del file system. Ext3 è in grado invece di assolvere entrambi i compiti, e persino il grado di consistenza si lascia impostare individualmente. Il più elevato grado di sicurezza (cioè integrità dei dati) si ottiene lanciando Ext3 nel modo data=journal che comunque può comportare un rallentamento del sistema, giacché vengono rilevati sia i meta-dati che i dati del journal. Un approccio relativamente recente consiste nell'utilizzo del modo data=ordered che provvede sia alla integrità dei dati che dei meta-dati, ma che usa il journaling solo per i meta-dati. Il driver del file system raccoglie tutti i blocchi di dati appartenenti ad un aggiornamento dei meta-dati. Questi blocchi vengono scritti sul disco prima dell'aggiornamento dei meta-dati. In questo modo si ha una consistenza dei meta-dati e dei dati senza un calo di performance. Una terza possibilità consiste nel data=writeback. In questo caso i dati possono essere scritti nel file system principale dopo che i meta-dati sono stati consegnati al journal. Questa opzione è considerata da tanti la migliore sotto il punto di vista delle prestazioni. Comunque può accadere che ricompaiano nei file vecchi dati a seguito di un crash e ripristino, mentre è garantita l'integrità interna del file system. Se non avete cambiato impostazioni, Ext3 viene inizializzato nel modo data=ordered.

Eseguite il log in come root ed eseguite tune2fs -j , con il quale create un journal Ext3 con i parametri di default. Per stabilire la dimensione del journal e su quale dispositivo debba risiedere, eseguite tune2fs -J con le opzioni desiderate riguardanti il journal size= e device=. Per maggiori informazioni sull programma tune2fs rimandiamo alla rispettiva pagina di manuale (tune2fs(8)).

Per assicurare che il file system Ext3 venga rilevato come tale, editate il file /etc/fstab: modificate il tipo di file system specificato per la partizione da ext2 in ext3. Le modifiche vengono applicate al prossimo reboot.

Per avviare un file system root impostato come partizione Ext3, includete i moduli ext3 e jbd in initrd. Per realizzare ciò, editate il file /etc/sysconfig/kernel per includere i due moduli sotto INITRD_MODULES ed eseguite il comando mkinitrd.

In fase di sviluppo di Reiser4, gli sviluppatori hanno posto l'accento sull'implementazione di caratteristiche rilevanti da un punto di vista della sicurezza. Reiser4 offre quindi tutta una serie di plug-in preposti a incrementare la sicurezza. Nuovo in tal senso sono anche i file «items.». Attualmente, le regole di controllo di accesso vengono definite per ogni file. Se vi è un grande file con informazioni che interessano diversi utenti, gruppi o applicazioni, i permessi di accesso diventano poco precisi per non escludere nessuna delle parti interessate. Reiser4 vi permette di suddividere questi file (appunto in «items»). I permessi di accesso quindi possono essere impostati separatamente per ogni utente con dei benefici del security management. Un esempio ad-hoc è /etc/passwd. Finora, solo root poteva leggere ed editare il file, mentre tutti gli altri utenti hanno solo l'accesso in lettura. Tramite gli item di Reiser4, potete suddividere questo file in una serie di items (un item per utente) e dare il permesso agli utenti o applicazioni di modificare i propri dati, ma non di accedere ai dati di altri utenti. Questo approccio ha dei risvolti possitivi sia per la sicurezza che la flessibilità.

In Reiser4 molte funzionalità del file system ed anche funzionalità esterne a cui ricorrono solitamente i file system sono stati implementati sotto forma di plug-in. Questi plug-in possono essere integrati in modo del tutto semplice nel sistema di base, quindi non si dovrà ricompilare il kernel o riformattare il disco rigido per intergrare delle nuove funzionalità al vostro file system.

Alla stregua di XFS, Reiser4 supporta l'allocazione posposta. Si veda Sezione 34.2.7, «XFS»; questa funzionalità, se utilizzata per i metadata, contribuisce ad un miglior layout in generale.

JFS segue alla stregua di ReiserFS l'approccio « metadata only». Al posto di una verifica dettagliata vengono rilevati solo le modifiche apportate ai meta-dati dovute a recenti attività del file system. Questo permette di velocizzare considerevolmente il ripristino. Attività contemporanee che richiedono diversi registrazioni di protocollo possono essere raccolte in un cosiddetto commit di gruppo, laddove il calo dal punto di vista della prestazione del file system viene compensato dal processo di scrittura multipla.

JFS si orienta alla struttura della directory. Nel caso di piccole directory consente di salvare direttamente il contenuto della directory nel suo inode. Per directory più capienti utilizza alberi bilanciati (ingl. B⁺trees) che semplificano notevolmente l'amministrazione delle directory.

Sotto Ext2 dovete indicare a priori la densità degli inode (memoria occupata da informazioni di natura amministrativa). Questo impone un limite massimo di file o directory per il vostro file system. Con JFS invece la memoria inode viene assegnata dinamicamente e gli esuberi vengono subito messi nuovamente a disposizione del sistema.

Al momento della generazione di un file system XFS, il block device del file system viene suddiviso in otto o più settori lineari di ugual misura, detti «allocation groups» che chiameremo gruppi di allocazione. Ogni «gruppo di allocazione» gestisce gli inode e la memoria libera. I gruppi di allocazione sono in pratica dei «file system nei file system». Visto che i gruppi di allocazione sono in una certa misura autonomi, il kernel ha la possibilità di indirizzarne contemporaneamente più di uno. Ecco "il segreto" della alta scalabilità di XFS. Questa suddivisione in gruppi di allocazione è particolarmente indicata per sistemi multi-processore.

La memoria libera e gli inode vengono gestiti da alberi B⁺ all'interno dei gruppi di allocazione. Gli alberi B⁺ contribuiscono in maniera determinante alla performance e alla scalabilità di XFS. Una caratteristica di XFS unica nel suo genere è la delayed allocation. XFS elabora l'assegnazione della memoria (ingl. allocation) bipartendo il processo. Una transazione «sospesa» viene memorizzata nella RAM e riservato il corrispondente spazio di memoria. XFS non stabilisce subito dove precisamente memorizzare i dati (cioè in quali blocchi del file system). Questa decisione viene rinviata il più possibile. Così file temporanei di breve durata non vengono scritti sul disco, visto che al momento di determinare la loro locazione sul disco sono già obsoleti. In tal modo XFS aumenta le prestazioni e riduce la frammentazione del file system. Dato però che una allocazione differita comporta un minor numero di accessi in scrittura rispetto ad altri file system, è probabile che la perdita di dati in seguito al verificarsi di un crollo durante il processo di scrittura risulterà essere maggiore.

Prima di scrivere i dati nel file system, XFS riserva lo spazio necessario per il file (ingl. preallocate). In questo modo si riduce notevolmente la frammentazione del file system, e si aumenta la performance, dato che il contenuto di un file non viene distribuito più lungo tutto il file system.