ext4

Il ciclo di sviluppo di Linux 7.0 sta attraversando le fasi finali, quelle in cui ogni intervento punta dritto alla stabilità. E tra le aree che hanno ricevuto più attenzione c'è il file system ext4, il punto di riferimento storico per tantissime distribuzioni. Non si parla di novità spettacolari o funzionalità inedite, ma di una serie di correzioni critiche che toccano il cuore stesso del modo in cui i dati vengono gestiti sul disco. Ext4 esiste da circa vent'anni, eppure continua a reggere il confronto con soluzioni più recenti. Supporta volumi fino a 1 EiB (exbibyte) e file singoli nell'ordine delle centinaia di terabyte, grazie a meccanismi come il journaling (che registra le operazioni per garantire l'integrità dei dati), l'allocazione ritardata dello spazio su disco e la gestione avanzata degli extent, cioè blocchi contigui di memoria che velocizzano l'accesso ai file. Le correzioni che arrivano con Linux 7.0 non sono marginali: riguardano la gestione delle strutture inode (dove risiedono i metadati dei file), l'assegnazione dei blocchi di memoria e la scrittura corretta dei dati sul supporto fisico. Test automatici e bug scoperti grazie a Google Syzkaller Buona parte delle anomalie risolte è emersa grazie a Google Syzkaller, un software di tipo fuzzer che genera input casuali per stressare il kernel Linux con sequenze automatiche di chiamate di sistema. Negli ultimi anni il suo contributo è stato decisivo, perché riesce a far emergere condizioni di errore che sarebbero quasi impossibili da riprodurre manualmente. Tra i problemi corretti ci sono memory leak (memoria allocata e mai più rilasciata, con conseguente consumo progressivo di risorse), bug di tipo use after free (tentativi di accedere ad aree di memoria non più valide) e situazioni che potevano mandare in crash l'intero sistema. Un caso emblematico: il rischio di blocco quando si disattivava la funzione di discard tramite un remount del file system e subito dopo si eseguiva lo smontaggio. Sembra una sequenza rara, ma nei sistemi automatizzati o nei dispositivi embedded capita più spesso di quanto si pensi. Una quota significativa degli interventi riguarda le cosiddette race condition, cioè scenari in cui due operazioni concorrenti generano risultati imprevedibili. In ext4, ad esempio, la riallocazione di un inode appena liberato poteva portare a un deadlock, una situazione in cui più processi restano bloccati in attesa reciproca senza mai proseguire. Un altro fix elimina un caso di use after free durante lo smontaggio simultaneo del file system. Allocazione dei blocchi, fsync e robustezza complessiva La gestione dello spazio su disco è uno dei pilastri di ext4, e qui le correzioni di Linux 7.0 vanno a toccare punti sensibili. Il sistema ora previene l'allocazione di blocchi appartenenti a gruppi corrotti, evitando di amplificare danni già presenti. Il meccanismo di allocazione multi blocco è stato aggiornato per non selezionare regioni segnate come compromesse, migliorando la resistenza in caso di errori hardware o corruzioni pregresse. C'è poi un fix importante legato alla chiamata fsync, fondamentale per assicurarsi che i dati vengano effettivamente scritti su disco. Ext4 si affida al journaling per preservare la coerenza del file system, quindi qualsiasi anomalia in quella fase può tradursi in perdita di dati o in uno stato incoerente dopo un crash. Gli sviluppatori hanno anche sostituito alcuni messaggi di errore generici con segnalazioni più precise, utili per la diagnostica. Molte delle condizioni corrette emergono solo sotto carichi elevati, con operazioni concorrenti o sequenze di sistema poco comuni. Proprio per questo la loro risoluzione nella fase finale del ciclo di sviluppo ha un peso rilevante: riduce il rischio di regressioni nella release stabile di Linux 7.0 e consolida la base per le distribuzioni che adotteranno questa versione nei prossimi mesi, soprattutto lato server e in contesti di storage intensivo dove ext4 resta ampiamente utilizzato.

ext4

Linux 7.0: lo sviluppo è quasi terminato