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

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).

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á.

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 .

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 )

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.

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.