¿Puede la pérdida inesperada de energía dañar una instalación de Linux?

22

Estoy desarrollando una aplicación en una placa integrada de Linux (ejecuta Debian), por ejemplo, Raspberry Pi, Beagle Board / Bone u olimex. Los tableros funcionan en un entorno en el que la electricidad se corta inesperadamente (es muy complicado colocar PSU, etc.) y sucedería todos los días un par de veces. Me pregunto si los cortes de energía inesperados causarían un bloqueo / problema en el sistema operativo Linux. Si es algo de lo que debería preocuparme, ¿qué sugeriría para evitar los daños en el sistema operativo contra los cortes de energía inesperados?

PD. La aplicación necesita escribir algunos datos en el medio de almacenamiento (tarjeta SD), creo que no sería adecuado montarlo como de solo lectura.

— Penetración
fuente

1

Manténgase alejado de ext2 (use ext3 o superior) en sistemas de archivos que modifique mucho, y debería estar bien en su mayor parte.

— LawrenceC

A menos que tenga mucho cuidado al especificar sus tarjetas SD, las tarjetas no garantizan nada si corta la alimentación inesperadamente. La tarjeta podría estar en medio de un movimiento de nivelación de desgaste, lo que llevaría a una corrupción extraña e inesperada, ¡que incluso podría estar en una partición diferente!

— derobert

No sé exactamente cómo hacerlo, pero es posible que desee considerar hacer que sus aplicaciones clave se basen en transacciones. De esa manera, puede tener su archivo actual y una copia de seguridad. Aplica las transacciones a su archivo actual y si eso falla, puede restaurar el archivo actual de la copia de seguridad y volver a aplicar las transacciones. Si cambia entre actual y copia de seguridad utilizando enlaces simbólicos o intercambiando nombres de archivos, eso puede suceder muy rápidamente con muchas menos posibilidades de error que con la copia. Después de una actualización exitosa, su archivo actual se convierte en su copia de seguridad y la copia de seguridad se convierte en la actual.

— Joe

Continuado. Esto casi funciona. El nuevo archivo actual también necesitaría las transacciones aplicadas, lo que requeriría procesar las transacciones dos veces, así que estoy seguro de que hay una mejor manera. En cualquier caso, aún puede ser mucho más rápido y seguro que copiar todo el archivo si es grande.

— Joe

14

Los cortes de energía inesperados pueden causar la corrupción de los datos del sistema de archivos; por ejemplo, si un proceso ha comenzado a escribir en un archivo, pero aún no ha terminado de escribirlo, el archivo puede terminar solo a la mitad. Ahora imagine si el corte de energía ocurre cuando está a la mitad de una actualización del kernel ...

Como escribió l0b0, el uso de un sistema de archivos de registro diario ayudará, ya que podrá realizar un seguimiento de lo que realmente se ha hecho. Además de la información de Wikipedia que enlazó l0b0, también puede estar interesado en /unix/12699/do-journaling-filesystems-guarantee-against-corruption-after-a-power-failure también .

Usted, como programador, obviamente debe considerar cuidadosamente cómo manejar la escritura en archivos para que se convierta en un proceso atómico (es decir, está completamente hecho o no está hecho en absoluto, pero nunca a la mitad). Es un tema bastante complejo.

— Jenny D
fuente

10

El proceso general en el código para proteger contra interrupciones de escritura que corrompen un archivo es que, en lugar de modificar file.name directamente, en su lugar, escribe un archivo completamente nuevo file.name.newversion, y luego usa los comandos delete / rename para reemplazar la versión anterior con el uno nuevo. Debe agregar un código de limpieza para recuperarse de una interrupción en cada paso; pero este enfoque siempre deja una buena copia del archivo en el disco. Esto puede afectar su diseño, ya que realiza mal la actualización de archivos grandes individuales o realiza cambios frecuentes en un solo archivo.

— Dan Neely

11

Para ayudar a minimizar la posibilidad de corrupción del sistema operativo, probablemente sea mejor tener particiones separadas de "sistema" y "datos" en la tarjeta SD. De esa manera, puede montar la partición "sistema" de solo lectura y usar un FS altamente resistente en la partición "datos".

Además, la mayoría de esas placas tienen requisitos de energía muy bajos, por lo que es posible una batería de respaldo. La placa del "piloto de LiPo" para Raspberry Pi se puede utilizar como UPS básico para proporcionar un apagado limpio en caso de pérdida de energía.

— Stu
fuente

5

Esto dependería de

si está utilizando un sistema de archivos de registro y
qué tan bien las aplicaciones pueden manejar el procesamiento abortado.

Considere, por ejemplo, una aplicación que procesa un archivo y escribe los resultados a medida que se calculan (una línea de salida por línea de entrada) en otro archivo. Si se corta la alimentación durante el procesamiento, y la misma aplicación se ejecuta después de reiniciar, no puede simplemente reiniciar el procesamiento desde el inicio del archivo de entrada; eso significaría que el archivo de salida contendrá información duplicada.

Podría ser muy difícil decir algo definitivo sobre un sistema complejo hipotético, pero la mayoría del software estable de Linux parece ser capaz de manejar los bloqueos bastante bien.

— l0b0
fuente

1

Dado que nadie mencionó ningún sistema de archivos específico: los sistemas de archivos más modernos (ext3, ext4, ntfs) pueden manejar los bloqueos mucho mejor que los sistemas de archivos más antiguos (ext2, ext, fat32) debido al registro en diario .

Suponiendo que el disco duro no se bloquea y no miente , una falla de energía completa no debería dañar el sistema de archivos. Sin embargo, los archivos individuales que se estaban escribiendo aún pueden estar dañados, por lo que si estaba en medio de la actualización del sistema operativo cuando se produjo el fallo de alimentación, aún es posible desactivar el sistema operativo.

— BlueRaja - Danny Pflughoeft
fuente