Prevenire il danneggiamento dei dati sull'unità ext4 / Linux in caso di interruzione dell'alimentazione

Ho alcune schede embedded che eseguono il BIOS American Megatrends con Linux incorporato come sistema operativo. Il problema che ho è che l'ide flash industriale sarà corrotto in caso di perdita di potenza. Li ho formattati come ext4. Ogni volta che succede, di solito posso riparare il flash con fsck, ma ciò non sarà possibile nelle nostre implementazioni. Ho sentito che disabilitare la memorizzazione nella cache di scrittura dovrebbe aiutare, ma non riesco a capire come farlo. Inoltre, c'è qualcos'altro che dovrei fare?

Ulteriori informazioni

L'unità è un modulo flash ide da 4 GB. Ho una partizione che è ext4. Il sistema operativo è installato su quella partizione e grub è il mio bootloader.

fdisk -l mostra / dev / sda come modulo flash con / dev / sda1 come partizione primaria.

Dopo una perdita di potenza, di solito non riesco a farcela interamente tramite gli script di avvio di avvio.

Quando monto l'unità su un altro PC, eseguo fsck / dev / sda1. Mostra sempre messaggi come

"zero datetime on node 1553 ... fix (y)?"

Li aggiusto e si avvia bene fino alla prossima perdita di potenza.

Quando arriverò in ufficio domani, pubblicherò l'output effettivo di fdisk -l

Questo è tutto ciò che so su come funziona il sistema. Non sono un ragazzo di sistemi, sono un ingegnere del software che ha l'abitudine di entrare in situazioni che sono al di fuori della sua descrizione del lavoro. So formattare le unità, installare un bootloader, scrivere software e hackerare su un sistema operativo.

Ecco l'output di dumpe2fs

#sudo dumpe2fs /dev/sda1
dumpe2fs 1.41.12 (17-May-2010)
Filesystem volume name:   VideoServer
Last mounted on:          /
Filesystem UUID:          9cba62b0-8038-4913-be30-8eb211b23d78
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      ext_attr resize_inode dir_index filetype extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash 
Default mount options:    (none)
Filesystem state:         not clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              245760
Block count:              977949
Reserved block count:     48896
Free blocks:              158584
Free inodes:              102920
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      239
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8192
Inode blocks per group:   512
Flex block group size:    16
Filesystem created:       Fri Feb  4 15:12:00 2011
Last mount time:          Sun Oct  2 23:48:37 2011
Last write time:          Mon Oct  3 16:34:01 2011
Mount count:              2
Maximum mount count:      26
Last checked:             Tue Oct  4 07:44:50 2011
Check interval:           15552000 (6 months)
Next check after:         Sun Apr  1 07:44:50 2012
Lifetime writes:          21 GB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:           256
Required extra isize:     28
Desired extra isize:      28
Default directory hash:   half_md4
Directory Hash Seed:      249d2b79-1e20-49a3-b324-6cb631294a63
Journal backup:           inode blocks

La cache di scrittura di solito non ha nulla a che fare con il BIOS, per lo più non esiste alcuna opzione per cambiare le impostazioni della cache del disco. Con Linux, l'utilizzo hdparm -W 0dovrebbe aiutare.

L'impostazione è persistente, quindi se non hai hdparm con cui giocare nei tuoi sistemi di produzione, dovresti essere in grado di disabilitare la cache di scrittura del disco su un sistema diverso e ricollegare il disco.

A proposito: secondo me l'idea di un filesystem di root non scrivibile (quindi il tuo sistema potrebbe avviarsi in una sorta di "modalità di recupero" e consentire l'accesso remoto anche se il filesystem scrivibile non è montabile per qualche motivo). E se puoi cambiare il design dell'hardware, prendi in considerazione l'uso di dispositivi mtd invece di dischi IDE / SATA con un filesystem compatibile con flash come jffs2 . Usiamo questa combinazione con diversi dispositivi integrati (principalmente soluzioni router VPN sul campo) da diversi anni con buoni risultati.

Aggiornamento: la radice del tuo problema sembra essere che stai eseguendo un filesystem ext4 con l'inserimento nel journal disabilitato - has_journalmanca Filesystem featuresdall'elenco. Chiudi semplicemente tutti i servizi, controlla se qualcosa ha ancora file aperti usando lsof +f -- /, rimonta la partizione di root con sola lettura mount -o remount,ro /, abilita il journal con tune2fs -O has_journal /dev/sda1e imposta la modalità journal "ordinata" come opzione di mount predefinita usando tune2fs -o journal_data_ordered /dev/sda1- dovrai ri eseguire fsck (preferibilmente da un sistema di salvataggio) e rimontare root / reboot dopo questa operazione.

Con queste impostazioni in atto, i metadati sono garantiti per essere recuperati dal journal anche in caso di improvvisa interruzione di corrente. I dati effettivi vengono anche scritti in modo coerente su disco, anche se è possibile che vengano visualizzati alcuni secondi prima dell'interruzione dell'alimentazione all'avvio. Se questo non è accettabile, potresti prendere in considerazione l'uso tune2fs -o journal_data /dev/sda1dell'opzione mount con il tuo filesystem - questo includerebbe tutti i dati scritti su disco nel journal - questo ovviamente ti darebbe una migliore coerenza dei dati ma a costo di una penalità prestazionale e un livello di usura più elevato sul tuo SSD.

Il suggerimento di scrivere cache è un buon inizio, ma sembra un difetto di progettazione architettonica. Su un sistema incorporato, probabilmente il flash interno NON deve essere montato R / W, tranne in rare circostanze. Dovresti davvero fare la maggior parte del lavoro in un filesystem di memoria e sincronizzare le modifiche al flash RW su un comando dell'utente o un intervallo regolare. È davvero raro che un sistema incorporato usi un normale filesystem (come ext4) in modalità rw durante il normale funzionamento. Se vi sono requisiti applicativi in ​​cui è necessario un sacco di spazio di archiviazione, è necessario considerare che la propria partizione di sistema sia diversa e progettarla in modo tale che la partizione dati possa essere fsck inclusa come parte dell'avvio.

Se hai bisogno di alcuni punti di partenza, guarderei come le persone installano i sistemi Diskless Linux:

http://frank.harvard.edu/~coldwell/diskless/

e inizia da lì. L'idea generale è che i file binari e i dati di sistema possano essere montati in sola lettura in modo che il file system non venga danneggiato. Tuttavia, devi essere in grado di scrivere in determinate aree, quindi hai bisogno di qualcosa per la memoria di solito filesystem / tmp, / var / tmp. Anche se alcune cose devono essere scrivibili, basta creare uno script per montare la partizione come r + w e quindi eseguire il commit delle modifiche, quindi tornare in sola lettura.

Un esempio davvero eccezionale di ciò è l'hardware delle Cicladi, il suo Linux incorporato e ogni volta che si apportano modifiche alla configurazione, è necessario eseguire uno script di salvataggio che in realtà confonde le configurazioni e le scrive sul flash.