¿Qué sistema de archivos ofrece la mejor protección para proteger los datos contra la corrupción debido a la pérdida de energía?

Estoy ejecutando un sistema integrado pequeño uClibcy busyboxbasado en un dispositivo x86. Estoy usando un initramfs pero también estoy montando un ext3directorio personalizado en un dispositivo flash compacto en modo IDE que estoy usando para almacenar datos de registro de medición persistente creados por una aplicación personalizada de c ++ escrita. Elegí el ext3sistema de archivos, ya que se recomienda para la seguridad contra la pérdida de energía cuando uso unidades CF en modo IDE en un par de libros que he leído ( Building Embedded Linux Systems de Karim Yaghmour y Embedded Linux Primer de Christopher Hallinan). Esto es particularmente importante y los datos son críticos.

Sin embargo, debido a algunos de los comentarios en mi pregunta anterior Confusión con la forma de restaurar archivos ext3 corruptos si se produce un corte de energía durante la escritura de un archivo , parecería que, de hecho, este sistema de archivos no ofrece la garantía de seguridad contra la corrupción de datos debido al poder pérdida. Entonces me gustaría saber si

1. ¿Es ext3realmente la mejor opción para esta configuración?
2. ¿La pérdida de energía durante una operación de escritura de disco solo corrompe la porción de datos que adjunto al archivo periódicamente o puede corromper todo el archivo?
3. ¿Los datos que no se escriben en el punto de pérdida de energía son completamente seguros? En particular, ¿existe algún riesgo de que mi initramfs.cpioarchivo también se corrompa?
4. ¿Hay algún método que pueda utilizar en el código de mi aplicación para proteger los datos (es decir, crear una partición adicional y escribir mis datos en imágenes espejo para que siempre haya 2 copias)? son aceptables

He visto y leído las respuestas a esta pregunta relacionada: ¿Garantizan los sistemas de archivos de diario contra la corrupción después de un corte de energía? , pero no cubre algunas de las cosas que me confunden.

Me doy cuenta de que estoy haciendo muchas preguntas, pero parece que a pesar de leer mucho material, he tenido una falla fundamental para comprender los riesgos para mis datos en caso de pérdida de energía.

Al igual que con todas las cosas relacionadas con la seguridad, no hay garantías, pero también debe equilibrar el riesgo (y el costo) con la probabilidad. Por experiencia (y he estado ejecutando docenas de * nix boxen desde la edad oscura), nunca he tenido una corrupción significativa del sistema de archivos causada por el poder.

Algunas de estas máquinas incluso se ejecutaban en sistemas de archivos no registrados en diario (usualmente ufs y ext2). Algunos de ellos estaban integrados, y algunos eran teléfonos móviles como el Nokia N900, por lo que no se garantizaba una buena fuente de alimentación.

No es que la corrupción del sistema de archivos no pueda suceder, es solo que la probabilidad de que ocurra es lo suficientemente baja como para no preocuparte. Aún así, no hay razón para no cubrir sus apuestas.

En respuesta a sus preguntas literales:

1. Al menos el primer libro al que hizo referencia se escribió antes ext4: cuando el autor sugiere usar ext3, en realidad están diciendo 'no use sistemas de archivos inestables o no registrados en el diario como ext2'). Intente ext4, es bastante maduro y tiene algunas opciones decentes para discos que no giran, lo que puede extender la vida útil de su dispositivo flash.
2. Lo más probable es que te pierda el último bloque o dos, no el archivo completo. Con un sistema de archivos con registro, esta será la única pérdida. Hay escenarios de falla en los que podría ver datos aleatorios esparcidos por el archivo, pero parecen tan probables como un micrometeorito que se estrella a través de su dispositivo integrado.
3. Ver 2. Nada es 100.00% seguro.

4. Si tiene un segundo canal IDE, pegue una segunda tarjeta CF allí y tome una copia de seguridad del sistema de archivos periódicamente. Hay algunas maneras de hacer esto: rsync, cp dump, dd, incluso utilizando la md(4)(RAID) del dispositivo (se agrega la segunda unidad de vez en cuando, se deja sincronizar, a continuación, quitar - si ambos dispositivos son en vivo todo el tiempo, corren el mismo riesgo de corrupción del sistema de archivos). Si usa LVM, incluso puede tomar instantáneas. Para un dispositivo integrado de recopilación de datos, simplemente usaría una solución ad hoc que monta el segundo sistema de archivos, copia sobre el registro de datos y lo desmonta inmediatamente. Si le preocupa que el dispositivo tenga una buena imagen de arranque, pegue una segunda copia del administrador de arranque y todas las imágenes de arranque necesarias en el segundo dispositivo y configure la computadora para que arranque desde cualquier tarjeta CF.

   No confiaría en una segunda copia en el mismo dispositivo porque los dispositivos de almacenamiento fallan con más frecuencia que los sistemas de archivos estables. Mucho más a menudo, en mi experiencia hasta ahora (en el trabajo, había una broma amarga sobre las posibilidades increíblemente altas de fallas de disco del viernes por la tarde. Fue un evento casi semanal durante un tiempo). Si el disco está girando o no, puede fallar. Si puede, mantenga sus huevos en dos cestas y protegerá mejor sus datos.

   Si los datos son particularmente confidenciales, haría visitas periódicas al dispositivo, cambiaría el CF de respaldo por uno nuevo y reiniciaría, dejando que fscktodos sus sistemas de archivos sean una buena medida.

Me parece que lo que puede lograr una implementación del sistema de archivos en el caso de una pérdida repentina de energía es limitado; después de todo, en realidad está interactuando con el hardware, entonces, ¿qué sucede entre el momento en que envía datos / instrucciones al hardware y cuándo obtiene una respuesta está fuera de su control. Si hubiera un sistema de archivos que pudiera eludir este problema, habría oído hablar de él.

Debido a eso, una estrategia para proteger los datos críticos se beneficiará más de las decisiones tomadas a nivel de hardware , por ejemplo, mediante el uso de una fuente de alimentación ininterrumpida. Probablemente esto no sea tan factible en su situación.

Usted ha dicho que el rendimiento no es realmente un gran problema, así que haga un uso juicioso fsync().

¿La pérdida de energía durante una operación de escritura de disco solo corrompe la porción de datos que adjunto al archivo periódicamente o puede corromper todo el archivo?

He estado usando sistemas de archivos extN personalmente y en servidores de Internet de tráfico medio bajo durante años, y como Alexios, no he visto mucha corrupción debido a fallas de energía (aunque, para ser justos, los servidores tienen UPS y no puedo recordar uno de ellos en realidad baja por ese camino). Un problema mucho más grave es la corrupción por falla del hardware, que diferentes sistemas de archivos pueden (nuevamente) ser más y menos capaces de resolver el problema, pero (nuevamente) esto está fundamentalmente fuera de su control y no pueden evitarlo.

Ocasionalmente he visto archivos perdidos o truncados a tamaño cero. Supongo que hay una buena posibilidad de que estos sean recuperables de alguna manera; esto no era necesario para mí, ya que estaban respaldados. La mayoría de las veces, si hay algún problema, fsckparece solucionarlo.

¿Los datos que no se escriben en el punto de pérdida de energía son completamente seguros? En particular, ¿existe algún riesgo de que mi archivo initramfs.cpio se corrompa también?

Creo que el riesgo es realmente muy bajo debido a una falla de energía, excepto el tipo de corrupción que el almacenamiento flash puede estar sujeto debido a la sobrecarga de energía que puede acompañar a fallas de energía, con lo que no tengo experiencia, pero espero que haya pensado e investigado esto.

¿Hay algún método que pueda usar en mi código de aplicación para proteger los datos?

Vale la pena repetir el punto sobre fsync () . Los objetos C ++ / iostream no tienen un método para esto (:: flush y :: sync no son fsync), pero todo lo que necesita es un descriptor de archivo.

ZFS es definitivamente un sistema de archivos protegido contra la corrupción por diseño y posiblemente el único. Sin embargo, no estoy seguro de la disponibilidad de implementaciones de ZFS (ya sea basadas en fusibles o nativas) para plataformas basadas en uClinux.

Hay al menos un sistema de archivos comercial que hace un trabajo tremendo asegurándose de que el sistema de archivos casi no se pueda corromper debido a fallas de energía y que los únicos datos que corres el riesgo de perder son los datos que se agregaron cuando se cortó la energía.

El lado negativo es que es muy costoso, en el lado positivo ofrecen un gran soporte. Debido al gasto, en realidad es solo una opción para productos de alto riesgo y / o de alto volumen. Al igual que los equipos incrustados críticos en, por ejemplo, la producción de petróleo y gas, que deben garantizar la integridad del sistema dentro de condiciones de funcionamiento "inciertas" (por ejemplo, apagones frecuentes, etc.).

Consulte DataLight (empresa) y / o producto " Reliance NITRO ". (Reliance es su solución heredada y segura pero no muy efectiva, reemplazada por Reliance NITRO ). Incluso si no tiene dinero para usar este sistema, tienen algunos artículos bastante buenos que discuten cómo funciona su sistema, por qué es más confiable que, por ejemplo, ext3 y ext4.

Mis disculpas si esto se lee como un anuncio, solo quería señalar las opciones.