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. 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.

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 resi consistenti, 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 occupa una quantità notevolmente inferiore di spazio 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 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 raggruppati in una transaction e 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 dopo un crash e ripristino, mentre è garantita l'integrità interna del file system. Se non avete cambiato impostazioni, Ext3 viene inizializzato nel modo data=ordered.

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 adatta 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 su cui posa il 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 fino ad un certo grado 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 “in sospeso” 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.