¿Es el "comportamiento esperado" de la partición ext3 de una unidad SSD la corrupción del sistema de archivos posterior a la pérdida de energía?

Mi compañía fabrica un dispositivo Linux Debian integrado que arranca desde una partición ext3 en una unidad SSD interna. Debido a que el dispositivo es una "caja negra" incrustada, generalmente se apaga de manera grosera, simplemente cortando la alimentación del dispositivo a través de un interruptor externo.

Esto normalmente está bien, ya que el diario de ext3 mantiene las cosas en orden, por lo que, aparte de la pérdida ocasional de parte de un archivo de registro, las cosas siguen avanzando bien.

Sin embargo, recientemente hemos visto una cantidad de unidades en las que después de varios ciclos de energía dura la partición ext3 comienza a desarrollar problemas estructurales, en particular, ejecutamos e2fsck en la partición ext3 y encuentra una serie de problemas como esos se muestra en la lista de resultados al final de esta pregunta. Ejecutar e2fsck hasta que deje de informar errores (o reformatear la partición) borra los problemas.

Mi pregunta es ... ¿cuáles son las implicaciones de ver problemas como este en un sistema ext3 / SSD que ha sido sometido a muchas paradas repentinas / inesperadas?

Creo que esto podría ser un signo de un problema de software o hardware en nuestro sistema, ya que entiendo que (salvo un error o problema de hardware) se supone que la función de registro diario de ext3 evita este tipo de errores de integridad del sistema de archivos. (Nota: entiendo que los datos de usuario no están registrados en el diario y, por lo tanto, pueden ocurrir archivos de usuario truncados / faltantes / truncados; específicamente estoy hablando aquí de errores de metadatos del sistema de archivos como los que se muestran a continuación)

Mi compañero de trabajo, por otro lado, dice que este es un comportamiento conocido / esperado porque los controladores SSD a veces reordenan los comandos de escritura y eso puede hacer que el diario ext3 se confunda. En particular, él cree que incluso con un hardware que funciona normalmente y un software libre de errores, el diario ext3 solo hace que la corrupción del sistema de archivos sea menos probable, no imposible, por lo que no debería sorprendernos ver problemas como este de vez en cuando.

¿Cuál de nosotros tiene razón?

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
fuente

¿Han pensado en cambiar a ext4 o ZFS?

— mdpc

He pensado en cambiar a ext4, al menos ... ¿eso ayudaría a resolver este problema? ¿ZFS estaría mejor aún?

— Jeremy Friesner

Ninguna opción solucionaría esto. Todavía usamos dispositivos con supercondensadores en ZFS, y se recomienda batería o caché protegida contra flash para ext4 en aplicaciones de servidor.

— ewwhite

Respuestas:

Ambos están equivocados (¿tal vez?) ... ext3 está haciendo lo mejor que puede con la eliminación abrupta de su almacenamiento subyacente.

Su SSD probablemente tenga algún tipo de caché integrada. No menciona la marca / modelo de SSD en uso, pero esto suena como un SSD de nivel de consumidor frente a un modelo de grado industrial o industrial .

De cualquier manera, el caché se usa para ayudar a unir las escrituras y prolongar la vida útil de la unidad. Si hay escrituras en tránsito, la pérdida repentina de poder es definitivamente la fuente de su corrupción. Los verdaderos SSD industriales y empresariales tienen supercondensadores que mantienen la energía el tiempo suficiente para mover los datos de la memoria caché al almacenamiento no volátil, de la misma manera que funcionan las memorias caché de los controladores RAID con respaldo de batería y flash .

Si su unidad no tiene un supercap, se pierden las transacciones en vuelo, de ahí la corrupción del sistema de archivos. Probablemente le digan a ext3 que todo está en un almacenamiento estable, pero eso es solo una función del caché.

— ewwhite
fuente

Lo siento por ti y todos los que votaron por esto, pero estás equivocado. Manejar la pérdida de escrituras en progreso es exactamente para qué sirve el diario, y siempre que la unidad informe correctamente si tiene un caché de escritura y obedezca los comandos para vaciarlo, el diario garantiza que los metadatos no serán inconsistentes. Solo necesita un caché de incursión supercap o con batería para poder habilitar el caché de escritura sin tener que habilitar barreras, lo que sacrifica parte del rendimiento para mantener la corrección de datos.

— psusi

@psusi El SSD en uso probablemente tiene caché explícitamente habilitado o se basa en un búfer interno independientemente de la configuración OS_level. Los datos en ese caché es lo que protegería un SSD habilitado para supercondensador .

— ewwhite

Los datos en la memoria caché no necesitan protección si habilita las barreras de E / S. La mayoría de las unidades de tipo consumidor se envían con el almacenamiento en caché de escritura deshabilitado de forma predeterminada y debe habilitarlo si lo desea, exactamente porque causa problemas de corrupción si el sistema operativo no tiene cuidado.

— psusi

@pusi Old ahora, pero mencionas esto:

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.

esa es la cuestión: debido a los controladores de almacenamiento que tienden a asumir discos más antiguos, las SSD a veces mienten sobre si los datos se vacían. Necesitas ese supercap.

— Joel Coel

Tienes razón y tu compañero de trabajo está equivocado. Salvo que algo salga mal, el diario se asegura de que nunca tenga metadatos fs inconsistentes. Puede consultar con hdparmpara ver si la memoria caché de escritura de la unidad está habilitada. Si es así, y no ha habilitado las barreras de E / S (desactivado por defecto en ext3, activado por defecto en ext4), entonces esa sería la causa del problema.

Las barreras son necesarias para forzar que la memoria caché de escritura de la unidad se vacíe en el momento correcto para mantener la coherencia, pero algunas unidades se comportan mal e informan que su memoria caché de escritura está desactivada cuando no lo está, o ignoran silenciosamente los comandos de descarga. Esto evita que el diario haga su trabajo.

— psusi
fuente

-1 para comprensión lectora ...

— ewwhite

@ewwhite, tal vez deberías intentar leer y escribir una respuesta útil en lugar de este insulto infantil.

— psusi

+1 esta respuesta probablemente podría mejorarse, como cualquier otra respuesta en cualquier control de calidad. Pero al menos proporciona algo de luz y pistas. @downvoters: mejoren ustedes mismos la respuesta, o comenten sobre posibles flujos, ¡pero rechazar esta respuesta sin la justificación adecuada es simplemente asqueroso!

— Alberto