Sistema de archivos que nunca se rompe (pérdida de datos aceptable)

Hay varios temas existentes que giran en torno a este tema, pero lo que busco es ligeramente diferente. Tengo una tarjeta SD en un Linux incrustado y sufre de pérdida de energía. Es posible que pueda modificar el hardware en algún momento, cerrarlo correctamente, etc., pero en este momento, me gustaría encontrar un sistema de archivos que sobreviva a la pérdida de energía sin problemas. La pérdida de datos es aceptable. Prefiero no perder más que el archivo que estoy escribiendo actualmente, pero prefiero perderlo todo que enfrentar un 'incapaz de montar', 'esperar estos 10 minutos fsck' o 'incapaz de crear nuevos archivo debido a este inodo algo algo error '. ¡El programa DEBE continuar!

Estoy haciendo un gran esfuerzo para asegurar esto. Estoy usando componentes de grado industrial, tengo perros guardianes de hardware, perros guardianes de software, internos, externos, reinicio de los programas, demonios que verifican constantemente la memoria, descriptores de archivos y demás, tengo perros guardianes que miran mis perros guardianes, que a su vez son observados por otros perros guardianes. ... ¿Pero parece que no puedo garantizar que la tarjeta SD pueda montarse y funcionar?

Mi mejor apuesta en este momento es usar JFS en la tarjeta SD, incluir fsck y fsck.jfs en mi instalación. (Agregar 600kb + comiendo mi ram y mi flash. Lo cual es malo). Y ejecuta fsck en cada inicio (quizás agregando mucho tiempo de arranque. Lo cual es algo malo). Aunque parece un poco triste.

¿Alguien sabe de una mejor manera o un mejor sistema de archivos?

ACTUALIZACIÓN: e2fsprogs-libs (dependencia de jfsutils) parece ser terriblemente difícil de compilar en mi distribución. Examinaré ZFS (aunque no es nativo de mi distribución. Y parece hacer mucho que no necesito).

UPDATE2: Some more info about my system and my tests: The SD card storage is a secondary, optional storage. The SD cards are 2Gb-8Gb industrial grade microSD. The SD card is mounted through my rc with a mount -t command. Options "noatime" but not "sync". My distribution is a custom Analog Device flavored uClinux, with a 3.10 kernel and a 1.21 busybox. My primary storage is a spi flash with jffs2. I've never had any issues with that. I don't even know if there is a fsck.jffs2 available. Nand flash on the other hand ... but that's a different story. The purpose of the SD card, is to store measurement data. The 'monitor' program will append results to a file and has strategic sync placements. When the file comes above a given size a new will be created. When a given number of files have been reached the oldest one will be deleted. If the current measurement file is lost due to power loss, it's no disaster. The files are usually at 50-100kb and 1 result is usually 1kb. This is just the initial development phase. Nothing is fixed. This is the first time I've been dealing with non-flash filesystems in embedded systems. (I got ext4 at my x86 servers.)

Empecé con vfat. El sistema de archivos predeterminado. (Pensé que las fábricas podrían tener una razón para elegirlo. Y si las cosas funcionan, realmente no me importa demasiado). Nunca he visto ningún problema de pérdida de energía en mis dispositivos vfat integrados. Sin embargo, he tenido problemas con FAT en WinCE. Sin embargo, cuando mi programa 'monitor' alcanzó los 100-200 archivos, se negó a crear más. Parece que FAT tiene un problema especial de límite de archivos en la raíz y uno ligeramente más grande en subdirectorios. Necesito poder crear 500-1000 archivos en 1 directorio. Entonces vfat no servirá.

Luego cambié a ext2. Sin embargo, no inserté un fsck al inicio. (No sabía que tenía que hacerlo). Dentro de un día, mi programa 'monitor' no pudo crear más archivos debido a un error 'inodo algo algo'. ¡Desastre!

Mi solución actual es ext2 con un "e2fsck -y" en el inicio. Hasta ahora parece prometedor. Pero el e2fsck y todo el concepto de 'fsck en el inicio' me molesta. El e2fsck por sí mismo está gastando más de 350kb de mi flash y ram principales. (Cuando no se está ejecutando). Lo que significa que es mi programa más grande. Es más grande que busybox. Casi rivaliza con mi núcleo.

He estado considerando ext3. Tiene metadatos en el diario, lo que no estaría de más. Sin embargo, tengo dudas sobre cuánto ayudará. Creo que con mis archivos pequeños y sincronizaciones controladas debería estar cubierto. Tiene una secuencia de escritura ordenada. Lo que significa que los datos también están algo registrados. Sin embargo, esto puede conducir a retrasos no deterministas. Lo cual es malo en mi situación. (Probablemente no sea un problema). También tiene una función de sincronización programada. P.ej. cometer cada 5 segundos Lo que está interfiriendo con mis propias sincronizaciones, creo. Demasiadas escrituras son malas para las tarjetas SD. Incluso los industriales. No puedo encontrar ninguna documentación sobre cómo deshabilitar esto. ¡Y ext3 todavía requiere que fsck se ejecute en cada inicio! Pero ext3 sigue siendo una posibilidad.

Ext4. Solucionará muchos de los problemas de rendimiento de ext3. Aunque realmente no necesito rendimiento. Y mi distribución no parece tener un mkfs.ext4 incorporado y un fsck.ext4. Quizás eso no sea un problema. Aunque podría ser. P.ej. e2progs-libs (dependencia de jfsutils) parece tener muchos problemas de compilación.

JFS, XFS, BRFSS. Todo soportado por mi kernel. Actualmente no está incluido en mi caja de herramientas de espacio de usuario. Todo parece ser sistemas bastante grandes y complejos. ¿Y todos parecen requerir un equivalente 'fsck' al inicio?

También he considerado lanzar mi propio sistema de archivos: siempre escriba 2 copias de la tabla de archivos. Al atravesar, elige el que tenga el CRC correcto y el número de secuencia más nuevo. Haz una secuencia de escritura de 2 etapas. Asignar temporalmente, arreglar en commit. No se necesita fsck. Sin embargo, me temo que podría ser un poco ingenuo.

ACTUALIZACIÓN3: Por cierto, la naturaleza de los sistemas embebidos (al menos este) es que son autónomos, desatendidos, fuera de alcance, y tienen que funcionar durante años. Programas como fsck que pueden requerir interacción humana me asustan.

Hay un poco de inconsistencia o, al menos, ambigüedad, en su historia aquí:

Prefiero perderlo todo que enfrentarme a un 'incapaz de montar', 'espera estos 10 minutos fsck'

Implica, aunque en realidad no lo dices, que este es un problema que realmente estás experimentando. Pero entonces:

e2fsprogs-libs (dependencia de jfsutils) parece ser infernalmente difícil de compilar en mi distribución.

Lo que significa que no tiene ningún fsck en absoluto , ya que e2fsprogs-libses una dependencia e2fsprogsque proporciona e2fsck. Entonces, ¿tal vez todavía está en una etapa de planificación aquí y ni siquiera ha probado el sistema con, por ejemplo ext4, sino que llegó a la conclusión de que debería comenzar con JFS? ¿Hay alguna razón particular para eso?

He notado en el intercambio de frambuesa pi (el almacenamiento primario de la pi también es una tarjeta SD) que un número significativo de usuarios parece estar muy frustrado por problemas de este tipo, a pesar de que la mayoría (incluido yo mismo) nunca lo ha tenido en todas. Al principio supuse que se trataba de personas que ignoraban el hecho de que el sistema debería cerrarse limpiamente, pero eso no es un punto difícil de entender cuando se explica, y hay personas que lo informan a pesar de que el sistema se ha apagado correctamente .

Ya ha dicho que necesita esto para poder tolerar cortes de energía (lo cual es bastante justo), pero menciono esto porque implica que hay algunas pis, o algunas tarjetas SD, o alguna combinación de ambas, que son propensas a corrompiendo el sistema de archivos debido a algún evento (¿sobretensión?) que ocurre regularmente, ya sea cuando se desconecta el enchufe o cuando se vuelve a colocar. Tampoco lo he visto, y ha habido mucho tiempo para que muchas personas lo intenten. CUALQUIER informe de alguien diciendo que ha cambiado a btrfs o jfs o lo que sea y ahora el problema está resuelto.

La otra cosa misteriosa acerca de esto es que incluso si las personas están tirando del cable, esto no debería resultar regularmente en un sistema de archivos inutilizable. Ciertamente, lo he hecho muchas veces con el pi, y anota, si no cientos de veces, con una caja de Linux normal (se cortó el suministro eléctrico, el sistema no responde, estoy agotado y enojado, etc.) y aunque he visto una pérdida de datos menor, nunca he visto un sistema de archivos dañado hasta el punto de ser inutilizable después de un rápido fsck.

Una vez más, suponiendo que todos estos informes sean ciertos (no veo por qué muchas personas mentirían al respecto), está sucediendo algo mucho más que simplemente no desmontar de manera limpia, pero parece que solo afecta a un pequeño porcentaje de usuarios, lo que implica nuevamente algún tipo de defecto de hardware común.

En el pi escribo -ya /forcefscken un script de arranque, por lo que en el siguiente arranque se ejecuta automáticamente y los problemas son fijos, independientemente de que este parece ser necesario o no. En un solo núcleo de 700 Mhz, esto lleva ~ 10 segundos para un sistema de archivos de 12 GB que contiene ~ 4 GB de datos. Así que "10 minutos" suena como un tiempo increíblemente largo, especialmente porque ya has dicho "¡Este es el pequeño sistema de archivos para escribir!".

También puede considerar llamar synca intervalos regulares.

Finalmente, debe actualizar la pregunta con detalles más concretos y específicos de los problemas que realmente ha encontrado y menos hipérboles. De lo contrario, se parece demasiado a un problema XY prematuro , que probablemente será ignorado rápidamente por personas con mucha experiencia y consejos potenciales para usted.

¡El programa DEBE continuar!

Bueno, este es un requisito común y los sistemas Linux son la mejor opción cuando se trata de elegir un sistema estable.

Sus esfuerzos también parecen no ir en la dirección correcta. Sin embargo, ¿qué puede hacer para obtener un sistema estable?

En el primer nivel puedes mejorar tu sistema de archivos:

• Úselo yournal_data_ordereden un ext3/ext4sistema de archivos, al crear o modificar con tune2fs.
• Con JFSuso --replay_journal_onlyal verificar.
• Habilite la reparación automática configurando FSCKFIX=yeslos initscripts.

Si esto no es suficiente, puede iniciar su sistema sin montar el disco defectuoso. En su lugar, cree un nuevo ramdiskmientras revisa y repara manualmente su disco defectuoso. Esto también puede ser automatizado por scripts.

En el siguiente nivel, deberá dejar su sistema integrado y leer algunos temas sobre Alta disponibilidad