La corruzione del filesystem post-improvviso con perdita di potenza nella partizione ext3 di un'unità SSD è "comportamento previsto"?

La mia azienda produce un dispositivo Debian Linux incorporato che si avvia da una partizione ext3 su un'unità SSD interna. Poiché il dispositivo è una "scatola nera" incorporata, di solito viene spento in modo maleducato, semplicemente tagliando l'alimentazione al dispositivo tramite un interruttore esterno.

Questo di solito va bene, poiché il journaling di ext3 mantiene le cose in ordine, quindi a parte la perdita occasionale di parte di un file di registro, le cose continuano a funzionare bene.

Tuttavia, recentemente abbiamo visto un certo numero di unità in cui dopo un numero di cicli di accensione forzata la partizione ext3 inizia a sviluppare problemi strutturali - in particolare, eseguiamo e2fsck sulla partizione ext3 e trova una serie di problemi come quelli mostrato nell'elenco di output in fondo a questa domanda. L'esecuzione di e2fsck fino a quando non interrompe la segnalazione degli errori (o la riformattazione della partizione) cancella i problemi.

La mia domanda è ... quali sono le conseguenze di vedere problemi come questo su un sistema ext3 / SSD che è stato sottoposto a molti arresti improvvisi / imprevisti?

La mia sensazione è che questo potrebbe essere un segno di un problema software o hardware nel nostro sistema, dal momento che la mia comprensione è che (salvo un bug o un problema hardware) la funzione di journaling di ext3 dovrebbe prevenire questo tipo di errori di integrità del filesystem. (Nota: ho compreso che i dati utente non sono registrati e quindi possono verificarsi file utente munged / mancanti / troncati; sto parlando in particolare qui di errori di file system-metadati come quelli mostrati sotto)

Il mio collega, d'altra parte, afferma che questo è un comportamento noto / previsto perché i controller SSD a volte riordinano i comandi di scrittura e ciò può causare confusione nel journal ext3. In particolare, egli ritiene che, nonostante l'hardware normalmente funzionante e il software privo di bug, il journal ext3 renda solo la corruzione del filesystem meno probabile, non impossibile, quindi non dovremmo sorprenderci nel vedere problemi di questo tipo di volta in volta.

Chi di noi ha ragione?

Embedded-PC-failsafe:~# ls
Embedded-PC-failsafe:~# umount /mnt/unionfs
Embedded-PC-failsafe:~# e2fsck /dev/sda3
e2fsck 1.41.3 (12-Oct-2008)
embeddedrootwrite contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Invalid inode number for '.' in directory inode 46948.
Fix<y>? yes

Directory inode 46948, block 0, offset 12: directory corrupted
Salvage<y>? yes

Entry 'status_2012-11-26_14h13m41.csv' in /var/log/status_logs (46956) has deleted/unused inode 47075.  Clear<y>? yes
Entry 'status_2012-11-26_10h42m58.csv.gz' in /var/log/status_logs (46956) has deleted/unused inode 47076.  Clear<y>? yes
Entry 'status_2012-11-26_11h29m41.csv.gz' in /var/log/status_logs (46956) has deleted/unused inode 47080.  Clear<y>? yes
Entry 'status_2012-11-26_11h42m13.csv.gz' in /var/log/status_logs (46956) has deleted/unused inode 47081.  Clear<y>? yes
Entry 'status_2012-11-26_12h07m17.csv.gz' in /var/log/status_logs (46956) has deleted/unused inode 47083.  Clear<y>? yes
Entry 'status_2012-11-26_12h14m53.csv.gz' in /var/log/status_logs (46956) has deleted/unused inode 47085.  Clear<y>? yes
Entry 'status_2012-11-26_15h06m49.csv' in /var/log/status_logs (46956) has deleted/unused inode 47088.  Clear<y>? yes
Entry 'status_2012-11-20_14h50m09.csv' in /var/log/status_logs (46956) has deleted/unused inode 47073.  Clear<y>? yes
Entry 'status_2012-11-20_14h55m32.csv' in /var/log/status_logs (46956) has deleted/unused inode 47074.  Clear<y>? yes
Entry 'status_2012-11-26_11h04m36.csv.gz' in /var/log/status_logs (46956) has deleted/unused inode 47078.  Clear<y>? yes
Entry 'status_2012-11-26_11h54m45.csv.gz' in /var/log/status_logs (46956) has deleted/unused inode 47082.  Clear<y>? yes
Entry 'status_2012-11-26_12h12m20.csv.gz' in /var/log/status_logs (46956) has deleted/unused inode 47084.  Clear<y>? yes
Entry 'status_2012-11-26_12h33m52.csv.gz' in /var/log/status_logs (46956) has deleted/unused inode 47086.  Clear<y>? yes
Entry 'status_2012-11-26_10h51m59.csv.gz' in /var/log/status_logs (46956) has deleted/unused inode 47077.  Clear<y>? yes
Entry 'status_2012-11-26_11h17m09.csv.gz' in /var/log/status_logs (46956) has deleted/unused inode 47079.  Clear<y>? yes
Entry 'status_2012-11-26_12h54m11.csv.gz' in /var/log/status_logs (46956) has deleted/unused inode 47087.  Clear<y>? yes

Pass 3: Checking directory connectivity
'..' in /etc/network/run (46948) is <The NULL inode> (0), should be /etc/network (46953).
Fix<y>? yes

Couldn't fix parent of inode 46948: Couldn't find parent directory entry

Pass 4: Checking reference counts
Unattached inode 46945
Connect to /lost+found<y>? yes

Inode 46945 ref count is 2, should be 1.  Fix<y>? yes
Inode 46953 ref count is 5, should be 4.  Fix<y>? yes

Pass 5: Checking group summary information
Block bitmap differences:  -(208264--208266) -(210062--210068) -(211343--211491) -(213241--213250) -(213344--213393) -213397 -(213457--213463) -(213516--213521) -(213628--213655) -(213683--213688) -(213709--213728) -(215265--215300) -(215346--215365) -(221541--221551) -(221696--221704) -227517
Fix<y>? yes

Free blocks count wrong for group #6 (17247, counted=17611).
Fix<y>? yes

Free blocks count wrong (161691, counted=162055).
Fix<y>? yes

Inode bitmap differences:  +(47089--47090) +47093 +47095 +(47097--47099) +(47101--47104) -(47219--47220) -47222 -47224 -47228 -47231 -(47347--47348) -47350 -47352 -47356 -47359 -(47457--47488) -47985 -47996 -(47999--48000) -48017 -(48027--48028) -(48030--48032) -48049 -(48059--48060) -(48062--48064) -48081 -(48091--48092) -(48094--48096)
Fix<y>? yes

Free inodes count wrong for group #6 (7608, counted=7624).
Fix<y>? yes

Free inodes count wrong (61919, counted=61935).
Fix<y>? yes


embeddedrootwrite: ***** FILE SYSTEM WAS MODIFIED *****

embeddedrootwrite: ********** WARNING: Filesystem still has errors **********

embeddedrootwrite: 657/62592 files (24.4% non-contiguous), 87882/249937 blocks

Embedded-PC-failsafe:~# 
Embedded-PC-failsafe:~# e2fsck /dev/sda3
e2fsck 1.41.3 (12-Oct-2008)
embeddedrootwrite contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Directory entry for '.' in ... (46948) is big.
Split<y>? yes

Missing '..' in directory inode 46948.
Fix<y>? yes

Setting filetype for entry '..' in ... (46948) to 2.
Pass 3: Checking directory connectivity
'..' in /etc/network/run (46948) is <The NULL inode> (0), should be /etc/network (46953).
Fix<y>? yes

Pass 4: Checking reference counts
Inode 2 ref count is 12, should be 13.  Fix<y>? yes

Pass 5: Checking group summary information

embeddedrootwrite: ***** FILE SYSTEM WAS MODIFIED *****
embeddedrootwrite: 657/62592 files (24.4% non-contiguous), 87882/249937 blocks
Embedded-PC-failsafe:~# 
Embedded-PC-failsafe:~# e2fsck /dev/sda3
e2fsck 1.41.3 (12-Oct-2008)
embeddedrootwrite: clean, 657/62592 files, 87882/249937 blocks

— Jeremy Friesner
fonte

Hai mai pensato di passare a ext4 o ZFS?

— mdpc,

Ho pensato di passare a ext4, almeno ... ciò aiuterebbe a risolvere questo problema? ZFS sarebbe ancora meglio?

— Jeremy Friesner il

Nessuna opzione risolverebbe questo problema. Usiamo ancora dispositivi con supercondensatori in ZFS e raccomandiamo cache protetta da batteria o flash per ext4 nelle applicazioni server.

— ewwhite,

Risposte:

Sbagli entrambi (forse?) ... ext3 sta affrontando il meglio che può avere con la sua memoria sottostante rimossa così bruscamente.

L'SSD probabilmente ha un qualche tipo di cache integrata. Non menzioni la marca / modello di SSD in uso, ma suona come un SSD di livello consumer rispetto a un modello di livello aziendale o industriale .

In entrambi i casi, la cache viene utilizzata per aiutare a fondere le scritture e prolungare la durata dell'unità. Se ci sono scritture in transito, l'improvvisa perdita di potere è sicuramente la fonte della tua corruzione. I veri SSD aziendali e industriali dispongono di supercondensatori che mantengono la potenza sufficiente per spostare i dati dalla cache all'archiviazione non volatile, allo stesso modo delle cache del controller RAID con batteria e flash .

Se l'unità non ha un supercap, le transazioni in volo vengono perse, quindi la corruzione del filesystem. ext3 probabilmente sta dicendo che tutto è su memoria stabile, ma questa è solo una funzione della cache.

— ewwhite
fonte

Mi dispiace per te e per tutti coloro che hanno votato a favore, ma ti sbagli di grosso. Gestire la perdita di scritture in corso è esattamente lo scopo del journal e finché l'unità riporta correttamente se dispone di una cache di scrittura e obbedisce ai comandi per scaricarlo, il journal garantisce che i metadati non saranno incoerenti. Hai solo bisogno di un supercaps o di una cache raid alimentata a batteria in modo da poter abilitare la cache di scrittura senza dover abilitare barriere, che sacrificano alcune prestazioni per mantenere la correttezza dei dati.

— psusi,

@psusi L'SSD in uso probabilmente ha la cache esplicitamente abilitata o si basa su un buffer interno indipendentemente dall'impostazione OS_level. I dati in quella cache sono protetti da un SSD abilitato a supercapacitor .

— ewwhite,

I dati nella cache non devono essere protetti se si abilitano le barriere IO. La maggior parte delle unità di tipo consumer viene fornita con la cache di scrittura disabilitata per impostazione predefinita e è necessario abilitarla se lo si desidera, proprio perché causa problemi di corruzione se il sistema operativo non è attento.

— psusi,

@pusi Vecchio ora, ma dici questo:

as long as the drive correctly reports whether it has a write cache and obeys commands to flush it, the journal guarantees that the metadata will not be inconsistent.

Questo è il fatto: a causa dei controller di archiviazione che tendono ad assumere dischi più vecchi, gli SSD mentono talvolta sul fatto che i dati vengano scaricati. Hai bisogno di quel supercap.

— Joel Coel,

Hai ragione e il tuo collega ha torto. Escludendo qualcosa che non va, il diario si assicura che non si abbiano mai metadati incoerenti. È possibile verificare con hdparmse la cache di scrittura dell'unità è abilitata. Se lo è, e non hai abilitato le barriere I / O (disattivato per impostazione predefinita su ext3, attivato per impostazione predefinita in ext4), questa sarebbe la causa del problema.

Le barriere sono necessarie per forzare lo svuotamento della cache di scrittura dell'unità al momento giusto per mantenere la coerenza, ma alcune unità si comportano male e segnalano che la loro cache di scrittura è disabilitata quando non lo è, oppure ignorano silenziosamente i comandi di svuotamento. Ciò impedisce al diario di svolgere il proprio lavoro.

— psusi
fonte

-1 per la comprensione della lettura ...

— ewwhite,

@ewwhite, forse si dovrebbe cercare la lettura, la scrittura e in realtà una risposta utile al posto di questo insulto infantile.

— psusi,

+1 questa risposta probabilmente potrebbe essere migliorata, come qualsiasi altra risposta in qualsiasi QA. Ma almeno fornisce un po 'di luce e suggerimenti. @downvoters: migliorare voi stessi la risposta o commentare possibili flussi, ma ridimensionare questa risposta senza un'adeguata giustificazione è semplicemente disgustoso!

— Alberto,