Come posso ottimizzare ext4 per affidabilità?

Dato che ext4 è stato introdotto come più affidabile di ext3 con i journal di blocco, c'è qualche possibilità di supporre che sia affidabile al 100%? Cosa succede se si abilita l'inserimento nel journal di blocco su di esso, che è disabilitato per impostazione predefinita?

Come guida per gli amici per spiegare il mio caso in modo più dettagliato: ho un dispositivo Linux incorporato, dopo che la tastiera e il monitor di installazione sono stati rimossi e funzionano autonomamente.

Il mio compito è assicurarmi che abbia un file system affidabile, quindi con errori non c'è modo di correggere manualmente i guasti sul dispositivo. Non posso costringere il mio cliente a utilizzare un up con ogni dispositivo per garantire l'assenza di guasti in caso di mancanza di corrente.

Cos'altro può offrirmi ext4 oltre al blocco journaling?

Grazie in anticipo.

No. Non puoi mai supporre che qualcosa sia affidabile al 100%.

I file system di journaling riducono al minimo la perdita di dati in caso di interruzione imprevista. Estensioni e barriere aiutano ancora di più, ma non possono eliminare tutti i problemi associati. Personalmente, non ho mai sperimentato la perdita di dati a causa della corruzione del file system durante l'utilizzo dei file system di journaling.

Inoltre, l'inserimento nel journal non è disabilitato per impostazione predefinita.

Ecco una buona panoramica di ext4 e dei suoi miglioramenti: http://kernelnewbies.org/Ext4

Una nuova funzionalità aggiunta a ext4 e introdotta con il kernel 3.5 è quella che è nota come "checksum dei metadati", che è un'altra caratteristica di ext4 che dovrebbe migliorare l'affidabilità e l'integrità della struttura del file system.

L'implementazione complessiva è ben spiegata nei neofiti del kernel :

I filesystem moderni come ZFS e Btrfs hanno dimostrato che garantire l'integrità del filesystem usando checksum è una caratteristica preziosa. Ext4 ha aggiunto la possibilità di archiviare checksum di vari campi di metadati. Ogni volta che viene letto un campo di metadati, il checksum dei dati letti viene confrontato con i checksum archiviati, se sono diversi significa che i medata sono danneggiati (si noti che questa funzione non copre i dati, solo le strutture di metadati interne e non ha capacità di "auto-guarigione").

Qualsiasi filesystem ext4 può essere aggiornato per usare i checksum usando il comando "tune2fs -O metadata_csum" o "mkfs -O metadata_csum" al momento della creazione. Una volta abilitata questa funzione in un filesystem, i kernel più vecchi senza supporto checksum saranno in grado di montarla solo in modalità di sola lettura.

Articoli come questo su kernel.org discutono ulteriormente in grande dettaglio tecnico di come l'uso dei checksum dei metadati può impedire che i metadati corrotti danneggino la struttura del file system.

Tuttavia, l'articolo avverte anche che:

Il codice di checksum dei metadati ha iniziato a diventare mainline in Linux 3.5 e a partire da 3.7-rc1 è in fase di test da parte degli utenti. Questo codice non è ancora solido.

Non è abilitato di default in Ubuntu 12.10, ed è probabilmente meglio non abilitarlo per il momento dopo i recenti problemi con il filesystem ext4, come notato qui .

È possibile disabilitare l'allocazione ritardata in ext4 (nodelalloc), il che renderebbe significativamente più probabile il recupero di più dati se / quando si subisse un blackout durante una scrittura, ma ciò comporterebbe il costo di una maggiore frammentazione del file sistema nel tempo.