¿Sistema de archivos de tarjeta SD a prueba de corrupción para Linux incorporado?

36

Recientemente tuvimos una situación bastante desagradable con nuestro cliente: el "quiosco" basado en Raspberry Pi solía mostrar datos de detección remota (nada más sofisticado que un navegador en modo quiosco que muestra una página web de actualización automática desde el servidor de recopilación de datos) no se pudo iniciar debido a corrupción del sistema de archivos. Ext4, requiere fsck manual, el sistema será parte de la presentación importante de mañana, se requiere servicio de inmediato. Por supuesto, no podemos exigir al cliente que apague el sistema de manera agradable cuando lo apague por la noche; el sistema simplemente debe soportar tal maltrato.

Me gustaría evitar tales situaciones en el futuro, y me gustaría mover el sistema operativo a un sistema de archivos que evitaría esto. Hay un montón de sistemas de archivos destinados a dispositivos MTD, donde hacer que se ejecuten en la tarjeta SD (un dispositivo de bloque estándar) requiere un salto de aro serio. También hay algunos otros sistemas de archivos (diarios, etc.) que cuentan con buena resistencia contra la corrupción. Todavía necesito ver una comparación razonable de sus pros y sus contras.

Qué sistema de archivos disponible en Linux proporcionaría la mejor resistencia contra la corrupción en fallas de energía inesperadas y no requeriría saltar a través de aros imposibles como yaffs2 para instalar en SD.

El equilibrio del desgaste es una ventaja, pero no un requisito: las tarjetas SD generalmente tienen sus propios mecanismos, si no son perfectos, aunque el sistema debe ser "cuidadoso con el flash" (los sistemas como NTFS pueden matar una tarjeta SD en un mes).

linux filesystems embedded failure-resistance SF.
fuente
1
Personalmente, iría por el otro lado y trabajaría en un apagado seguro en el apagado, probablemente usando una tapa para proporcionar suficiente empuje para ejecutar un apagado.
Scott Seidman
Me encantaría ver a alguien diseñar el módulo que proporcione la potencia suficiente para un apagado limpio, junto con el soporte del sistema necesario para prestar atención a la advertencia y en realidad apagarse. Parece que debería ser un compañero sensato para las máquinas Pi, BeagleBone y otras máquinas Linux pequeñas, pero no parece existir como un producto marcado para los usuarios de esas máquinas.
RBerteig
@ScottSeidman: Siendo RPi, bastante hambriento de energía, piense en 800 mA a 5 V durante 15 segundos. No es una cosa de condensadores a menos que invierta en una batería completa de supercaps.
SF.
@RBerteig: una caja con una batería recargable, electrónica adecuada para cargar, estabilizar el voltaje de salida (posiblemente un paso más alto que el de la batería), enviar una señal de apagado, cortar la potencia de salida después de que se complete el apagado, apagarse hasta que se restablezca la alimentación de entrada - seguro que todo es factible, pero si no lo fabrica a granel, casi duplica el costo del RPi (aunque en el caso de ese quiosco, el televisor es 10 veces más caro ...)
SF.
1
@SF. - Tenga en cuenta que hay dos problemas con un sistema de archivos robusto contra powerfail. El primero es que el FS en sí mismo sea robusto, el segundo es que el hardware subyacente no miente sobre el vaciado de datos al disco. Sé que los discos giratorios se han mentido en los últimos años para aumentar su rendimiento aparente, querrás asegurarte de que tus tarjetas SD no estén haciendo lo mismo.
Michael Kohne

Respuestas:

17

BTRFS ofrecería la mejor resistencia contra la corrupción en una sola tarjeta SD en modo RAID1 con el fregado automático ejecutado en cada período de tiempo predefinido.

Los beneficios:

  1. retener la capacidad de RW al sistema de archivos
  2. Sistema de archivos moderno y completo con opciones muy útiles para un RPi, como compresión transparente e instantáneas
  3. diseñado con memoria flash en mente (entre otras cosas)

Aquí está cómo hacerlo:

Ejecuto mi RaspberryPi en ArchARM Linux y mi tarjeta está en el lector SD, así que modifique esas instrucciones en consecuencia para otras distribuciones e interfaces / dev.

Aquí hay un diseño de partición de ejemplo:

/dev/mmcblk0p1: fat32 boot partition
/dev/mmcblk0p2: to be used as btrfs partition
/dev/mmcblk0p3: to be used as btrfs partition (mirrored with the above)
/dev/mmcblk0p4 (optional): swap

Para obtener btrfs en RAID1, debe crear el sistema de archivos de esta manera:

mkfs.btrfs -m raid1 -d raid1 /dev/mmcblk0p2 /dev/mmcblk0p3

Luego, vaya rsync -aAXva su sistema respaldado anteriormente.

Para que arranque desde BTRFS en raid1, debe modificar initramfs . Por lo tanto, debe hacer lo siguiente mientras todavía tiene su sistema ejecutándose en su antiguo sistema de archivos.

Raspberry normalmente no usa mkinitcpio, por lo que debe instalarlo. Luego, debe agregar "btrfs" a la matriz MODULES en mkinitcpio.conf y recrear initramfs con

mkinitcpio -g /boot/initrd -k YOUR_KERNEL_VERSION

Para saber qué escribir en lugar de YOUR_KERNEL_VERSION, ejecute 

ls /lib/modules

Si actualiza el kernel, DEBE recrear initramfs ANTES de reiniciar.

Luego, debe modificar los archivos de arranque de RPi.

En cmdline.txt, necesitas tener

root=/dev/mmcblk0p2 initrd=0x01f00000 rootfstype=btrfs

y en config.txt, necesitas agregar

initramfs initrd 0x01f00000

Una vez que haya hecho todo eso y haya arrancado con éxito en su sistema btrfs RAID1, lo único que queda es configurar un fregado periódico (cada 3-7 días) con el temporizador systemd (preferido) o cron (dcron) de esta manera:

btrfs scrub start /

Se ejecutará en su sistema de archivos comparando sumas de verificación de todos los archivos y reparándolos (reemplazándolos con la copia correcta) si encuentra algún daño.

La combinación de BTRFS RAID1, un solo medio y Raspberry Pi hacen que esto sea bastante arcano. Tomó algo de tiempo y trabajo juntar todas las piezas, pero aquí está.

Lockheed
fuente
¿Debo agregar el 'scrub' después de cada arranque también?
SF.
@SF. No, no es necesario. Exfoliación periódica cada X días es suficiente. Preferiblemente durante las horas de menor uso.
lockheed
Lo siento, no entiendo: si mantengo una /bootpartición gruesa, ¿todavía necesito modificar initramfs?
Bex
Bex, si. Tiene que ver con la función raid1 de btrfs, no con la partición fat / boot.
lockheed
@@@ ACTUALIZACIÓN: @@@ A partir de ahora, uno puede intentar usar el modo dup en lugar de RAID1: "mkfs.btrfs --data dup --metadata dup" pero no estoy 100% seguro de que sea tan resistente como RAID1 en un solo disco.
lockheed
10

Bueno, el almacenamiento flash es más deseable que el almacenamiento magnético, por múltiples razones, pero para esta aplicación lo diré principalmente porque no hay partes móviles. Dicho esto, no creo que haya un sistema de archivos 'a prueba de corrupción', pero hay algunos sistemas de archivos robustos (ext4 es uno), así como algunas tácticas para ayudar a mitigar la corrupción.

Disco RAM

Si la imagen del RPi no tiene que cambiar, y parece que no lo hace, si nada intentará (o debería intentar) escribir en el disco, intente utilizar un sistema de archivos raíz creado para descomprimirlo en la RAM . La idea aquí es que tiene un sistema de archivos raíz comprimido en el arranque que se descomprime en la RAM. Todos los cambios ocurren en el disco RAM, por lo que efectivamente no hay escritura en la tarjeta SD, solo lectura al inicio. Esto debería reducir las lecturas / escrituras en su unidad, preservando la vida útil de la misma. Esto es similar a lo que se hace cuando arrancas Linux desde un CD , y es una de las primeras cosas que sucede cuando arranca Linux .

MDMoore313
fuente
10

Yo iría por otro lado y simplemente usaría un sistema de archivos de solo lectura. Nunca obtengo mi raspberry pi lo suficientemente estable cuando uso un sistema de archivos raíz de lectura y escritura en la tarjeta sd. Puede arrancar su raíz a través del kernel cmdline (ro) o usar un initramfs con piggyback, incluido su sistema completo.

Ambos son posibles de crear con mi sistema de construcción casero OpenADK. ( http://www.openadk.org )


fuente
El sistema de archivos RO ayuda ... pero no resuelve el problema por completo.
Piskvor
7

Bueno, el problema que tiene aquí es que el uso de un sistema de archivos "moderno" como el ext * puede desgastar su tarjeta SD; según mi experiencia, eso sucede dentro de un año, o el próximo año si tomas el extremo superior.

El problema es que los sistemas de archivos modernos siempre están moviendo bloques para evitar la fragmentación de los datos. Lo que es bueno en los discos giratorios, donde desea que se recopilen todos sus datos al cargarlos en la caché. La desventaja es que está haciendo más escrituras que no se pueden almacenar en caché ya que la ordenación se maneja cuando no hay muchas E / S.

También sucede cuando manejas una gran cantidad de registros, lo que quizás quieras hacer al depurar tu dispositivo incorporado. Las escrituras de registro son el peor tipo de escrituras, porque hay muchas escrituras pequeñas que ocurren regularmente, lo que genera mucha fragmentación.

Como usted dice que su sistema también está manejando los datos del sensor, es muy probable que los almacene en el flash a medida que vienen. Y son tan malos como los datos de registro.

Entré en el mismo problema con el que te encuentras, y aquí están mis conclusiones. Traté de buscar tarjetas SD que se vendieran como "más robustas", es decir, que pudieran manejar más escrituras que las otras, pero no encontré ningún punto de referencia en el mercado que se centre en eso, a diferencia de los puntos de referencia en el SSD. Como todos se centran solo en la velocidad, es imposible saber la cantidad de escrituras por bloque de memoria y la tecnología utilizada en la tarjeta SD.

Sin embargo, he notado que los sandisks de grado "industrial" tenían una vida útil más larga que los nombres sin nombre. Lo cual no es sorprendente, cuando pagas más, obtienes más.

Pero al final, con el registro intensivo habilitado, no encontré ninguna tarjeta SD que tenga una vida útil más larga que un par de años, siendo un año donde ocurre la mayor cantidad de muertes.

La solución que se me ocurrió son las soluciones de @ BigHomie y @wbx ': use un sistema de archivos extX de solo lectura (ya que no es necesario el registro en diario, incluso puede recurrir al buen ext2). Y si desea mantener registros dentro de la sesión o escribir archivos temporales, siempre puede usar un DISCO RAM.

Solo existen tutoriales y scripts que ayudan a llenar el disco RAM con datos de las partes de solo lectura para que pueda editarlos para la sesión.

NB: mi experiencia ha sido usar Angstrom Linux en un Beaglebone, entre una prueba de 20 dispositivos sensores. El registro de ese sistema fue muy detallado, utilizando el sistema de diario de systemd.

zmo
fuente
4

Linux ofrece muchos sistemas de archivos. ext4 es en el que tengo más confianza. En caso de duda, ext4 debe usarse para cualquier partición que se montará lectura-escritura.

El sistema de archivos ext2 es mucho más frágil. Es un sistema de archivos perfectamente bueno para sistemas que pueden montarlo de solo lectura o desmontarlo correctamente. Pero la corrupción es extremadamente probable con una falla de energía en ext2 .

La otra opción podría ser considerar jfs aunque el sistema de archivos jfs no sea confiable en algunas versiones de Linux. La corrupción es menos probable con jfs que con ext4 . Jfs también tiene un tiempo de montaje rápido y tiempo de verificación del sistema de archivos.


fuente
2
Sí, ext4 es excelente y lo uso para la mayoría de mis servidores. PERO esta pregunta es sobre sistemas de archivos para el sistema raíz en tarjetas SD . Este es un ambiente diferente. ¿Su consejo es general o realmente recomienda usar tarjetas ext4?
guettli