Ext4 abbandona una modalità journal: cosa cambia per gli utenti Linux

Si fa un gran parlare, in questi giorni, dell’abbandono – da parte di ext4 – di data=journal, una modalità di scrittura molto prudente, costosa sul piano delle prestazioni. L’accantonamento entra nel ciclo di sviluppo di Linux 7.3 e la rimozione è prevista per gennaio 2028.

Il journal è una zona riservata nella quale il file system ext4 annota le modifiche che devono essere completate. Serve soprattutto quando qualcosa va storto: blackout, crash del kernel, reset improvviso. Al riavvio, Linux può rileggere quelle informazioni e ricostruire uno stato coerente del file system, evitando che un’operazione interrotta lasci strutture interne danneggiate.

Non è un backup e non conserva una cronologia dei documenti: il journal aiuta il file system a gestire correttamente operazioni che, al momento del crash, potevano trovarsi a metà.

Perché ext4 usa un journal come ancora di salvezza

Quando un programma modifica un file, il sistema non deve aggiornare soltanto i byte che compongono il suo contenuto. Esistono anche i metadati: inode, dimensione, permessi, directory, riferimenti ai blocchi occupati sul dispositivo e altre informazioni che descrivono la struttura del file system.

Sono modifiche che non avvengono tutte nello stesso istante: se l’alimentazione dovesse venire a mancare tra un passaggio e l’altro, l’unità di memorizzazione potrebbe contenere una combinazione incoerente di dati vecchi e nuovi. Ext4 utilizza quindi JBD2, il componente del kernel incaricato di gestire il journal, raggruppando le modifiche in transazioni.

Dopo un arresto anomalo, JBD2 può eseguire il cosiddetto journal replay: legge le transazioni che risultavano completate e consente a ext4 di riportare le proprie strutture in uno stato affidabile. Proprio grazie a queste accortezze dopo un crash non serve più scansionare l’intero file system come accadeva un tempo.

Nella configurazione normale, data=ordered, ext4 registra nel journal principalmente i metadati. I dati veri e propri sono scritti direttamente nella posizione definitiva sul dispositivo. È un compromesso che mantiene buone garanzie di coerenza senza costringere il sistema a duplicare ogni scrittura.

Con data=journal, invece, anche il contenuto dei file passa prima dal journal: soltanto in un secondo momento i dati sono trasferiti nella posizione definitiva. Com’è evidente, in molti casi, le stesse informazioni finiscono sul dispositivo due volte.

Cosa cambia davvero per chi usa Linux

Per un normale sistema Linux con ext4 l’impatto è quasi nullo: desktop, notebook e moltissimi server usano già data=ordered, quindi continueranno a funzionare come prima. Non serviranno formattazioni, conversioni del file system o modifiche manuali.

L’intervento riguarda invece chi ha configurato esplicitamente data=journal, magari molti anni fa, attraverso il comando mount oppure in /etc/fstab.

Con i kernel che recepiscono l’accantonamento della modalità, i sistemi sui quali risulta abilitata mostreranno un avviso; l’obiettivo è dare agli amministratori il tempo di individuare le configurazioni interessate prima della rimozione prevista per il 2028.

Il file system ext4 continuerà comunque a usare il journal e JBD2, proteggendo i metadati. A sparire sarà soltanto la modalità che fa transitare nel journal anche tutti i dati dei file. PostgreSQL, MySQL, SQLite e altri programmi di questo tipo utilizzano inoltre propri meccanismi di protezione, come WAL, redo log o journal applicativi. In tali scenari, far transitare ogni dato anche attraverso il journal del file system può significare duplicare parte del lavoro senza ottenere necessariamente un vantaggio proporzionato.

Perché gli sviluppatori rimuovono la modalità

Dietro la decisione non c’è soltanto una riflessione sulle prestazioni: ogni modalità speciale tenuta in vita costituisce codice da mantenere, testare e verificare ogni volta che ext4 evolve. Se una funzione viene usata poco ma interagisce con molte parti del percorso di I/O, il suo costo di manutenzione cresce.

Theodore Ts’o, maintainer storico di ext4, ha quindi avviato il percorso di accantonamento fissando una finestra sufficientemente lunga. La discussione sulla mailing list linux-ext4 mostra che l’idea non è rimuovere data=journal all’improvviso, ma segnalare prima la presenza della configurazione e lasciare il tempo necessario per migrare.