Prevenir la corrupción de datos en la unidad ext4 / Linux en caso de pérdida de energía

Tengo algunas placas integradas que ejecutan la BIOS American Megatrends con Linux integrado como sistema operativo. El problema que tengo es que las ideas de flash industrial se corromperán con la pérdida de energía. Los tengo formateados como ext4. Cuando esto sucede, generalmente puedo arreglar el flash con fsck, pero esto no será posible en nuestras implementaciones. He oído que deshabilitar el almacenamiento en caché de escritura debería ayudar, pero no puedo entender cómo hacerlo. Además, ¿hay algo más que deba hacer?

Más información

La unidad es un módulo flash de 4 gb ide. Tengo una partición que es ext4. El sistema operativo está instalado en esa partición y grub es mi gestor de arranque.

fdisk -l muestra / dev / sda como mi módulo flash con / dev / sda1 como mi partición primaria.

Después de una pérdida de energía, generalmente no puedo hacerlo completamente a través de los scripts de inicio de arranque.

Cuando monte la unidad en otra PC, ejecuto fsck / dev / sda1. Siempre muestra mensajes como

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

Los reparo y arranca bien hasta la próxima pérdida de energía.

Cuando llegue a la oficina mañana, publicaré la salida real de fdisk -l

Esto es todo lo que sé sobre cómo funciona el sistema. No soy un experto en sistemas, soy un ingeniero de software que tiene la costumbre de meterse en problemas que están fuera de la descripción de su trabajo. Sé cómo formatear unidades, instalar un gestor de arranque, escribir software y piratear un sistema operativo.

Aquí está la salida de 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

El caché de escritura generalmente no tiene nada que ver con el BIOS, principalmente no hay opción para cambiar la configuración de caché de disco allí. Con Linux, usar hdparm -W 0debería ayudar.

La configuración es persistente, por lo que si no tiene hdparm para jugar en sus sistemas de producción, debería poder deshabilitar la caché de escritura de disco en un sistema diferente y volver a conectar el disco.

Por cierto: apoyaría la idea de un sistema de archivos raíz no modificable (por lo que su sistema podría arrancar en una especie de "modo de recuperación" y permitir el acceso remoto incluso si el sistema de archivos modificable no se puede montar por alguna razón). Y si puede cambiar el diseño del hardware, considere usar dispositivos mtd en lugar de discos IDE / SATA con un sistema de archivos compatible con flash como jffs2 . Hemos estado utilizando esta combinación con varios dispositivos integrados (en su mayoría soluciones de enrutador VPN en el campo) durante varios años con buenos resultados.

Actualización: la raíz de su problema parece ser que está ejecutando un sistema de archivos ext4 con el diario deshabilitado; has_journalfalta en la Filesystem featureslista. Simplemente apague todos los servicios, verifique si hay algo que todavía tenga archivos abiertos lsof +f -- /, vuelva a montar su partición raíz con solo lectura mount -o remount,ro /, habilite el diario con tune2fs -O has_journal /dev/sda1y configure el modo de diario "ordenado" como la opción de montaje predeterminada usando tune2fs -o journal_data_ordered /dev/sda1- tendrá que volver a ejecute fsck (preferiblemente desde un sistema de rescate) y vuelva a montar root / reiniciar después de esta operación.

Con esta configuración, se garantiza que los metadatos sean recuperables del diario incluso en el caso de una falla repentina de energía. Los datos reales también se escriben consistentemente en el disco, aunque es posible que vea datos de varios segundos antes de que se pierda el corte de energía en el arranque. Si esto no es aceptable, podría considerar usar la tune2fs -o journal_data /dev/sda1opción de montaje con su sistema de archivos, esto incluiría todos los datos escritos en el disco en el diario, esto obviamente le daría una mejor consistencia de datos, pero a costa de una penalización de rendimiento y un mayor nivel de desgaste en tu SSD.

La sugerencia de caché de escritura es un buen comienzo, pero esto suena como un defecto de diseño arquitectónico. En un sistema embebido, el flash interno probablemente NO debería montarse R / W, excepto en circunstancias excepcionales. Realmente deberías estar haciendo la mayor parte del trabajo en un sistema de archivos de memoria y sincronizando los cambios nuevamente en el flash RW con algún comando del usuario o intervalo regular. Es muy poco común que un sistema integrado use un sistema de archivos normal (como ext4) en modo rw durante el funcionamiento normal. Si hay algún requisito de aplicación en el que necesita mucho espacio de almacenamiento, debe considerar que la partición de su sistema sea diferente y diseñarla de tal manera que la partición de datos pueda ser fsck -y'ed como parte del inicio.

Si necesita algunos puntos de partida, vería cómo las personas configuran sistemas Linux sin disco:

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

y empezar desde allí La idea general es que los datos y los archivos binarios del sistema se pueden montar de solo lectura para que su sistema de archivos no se corrompa. Sin embargo, debe poder escribir en ciertas áreas, por lo que necesita algo para almacenar en memoria el sistema de archivos / tmp, / var / tmp. Incluso si ciertas cosas necesitan ser editables, simplemente cree un script para montar la partición como r + w y luego confirme los cambios, luego regrese a solo lectura.

Un gran ejemplo de esto es el hardware de Cyclades, su Linux integrado y cada vez que realiza cambios de configuración, debe ejecutar un script de guardado que realmente reencuentre las configuraciones y las escriba en la memoria flash.