¿Debo fsck ext3 en el sistema embebido?

Question

Tenemos una serie de sistemas integrados que requieren acceso r / w al sistema de archivos que reside en el almacenamiento flash con emulación de dispositivo de bloque. Nuestra plataforma más antigua se ejecuta en flash compacto y estos sistemas han estado en uso durante más de 3 años sin que se ejecute un solo fsck durante el arranque y hasta ahora no tenemos fallas atribuidas al sistema de archivos o CF.

En nuestra plataforma más nueva, usamos USB-flash para la producción inicial y ahora estamos migrando a Disk-on-Module para almacenamiento en r / w. Hace un tiempo tuvimos algunos problemas con el sistema de archivos en muchos de los dispositivos que se ejecutan en almacenamiento USB, así que habilité e2fsck para ver si eso ayudaría. Al final resultó que habíamos recibido un envío de memorias flash malas, así que una vez que fueron reemplazadas, el problema desapareció. Desde entonces he deshabilitado e2fsck ya que no teníamos indicios de que hiciera que el sistema fuera más confiable e históricamente hemos estado bien sin él.

Ahora que hemos comenzado a instalar unidades de disco en módulo, he comenzado a ver errores en el sistema de archivos nuevamente. De repente, el sistema no puede leer / escribir ciertos archivos y si trato de acceder al archivo desde la consola de emergencia, obtengo & Quot; Error de entrada / salida & Quot ;. Volví a habilitar e2fsck y se corrigieron todos los archivos.

O'Reilly's " Creación de sistemas Linux embebidos " recomienda ejecutar e2fsck en sistemas de archivos ext2 pero no lo menciona en relación con ext3, por lo que estoy un poco confundido sobre si debo habilitarlo o no.

¿Cuáles son sus opiniones sobre la ejecución de fsck en un sistema integrado? Estamos considerando poner binarios en la partición ar / o y solo los archivos que deben modificarse en la partición ar / w en el mismo dispositivo flash para que fsck nunca pueda eliminar accidentalmente binarios importantes del sistema. ¿Alguien tiene alguna experiencia con ese tipo de configuración? (bueno / malo)?

Answer 1

Creo que la respuesta a su pregunta se relaciona más con los tipos de requisitos de coherencia que su aplicación tiene en relación con sus datos. Es decir, ¿qué debe garantizarse si se pierde la energía sin un apagado formal del sistema? En general, ninguno de los sistemas de archivos de tipo de sistema operativo de escritorio maneja todo esto tan bien sin el cierre / sincronización de archivos de aplicaciones específicas y el vaciado de las memorias caché de disco, etc. hecho comprometido con los medios de comunicación.

Ejecutar fsck corrige el sistema de archivos, pero sin el cuidado anterior, no hay garantías sobre qué cambios que realizó se mantendrán realmente. es decir: no es exactamente determinista lo que perderá como resultado de la falla eléctrica.

Estoy de acuerdo en que colocar sus archivos binarios u otros datos importantes de solo lectura en una partición de solo lectura por separado ayuda a garantizar que no puedan ser arrojados erróneamente debido a una corrección fsck en las estructuras del sistema de archivos. Como mínimo, será útil colocarlos en un subdirectorio diferente de la raíz de donde se encuentran los datos R / W. Pero en ambos casos, si admite actualizaciones de software, aún debe tener un esquema para tratar de escribir & Quot; read-only & Quot; áreas de todos modos.

En nuestra aplicación, en realidad mantenemos un par de directorios para cosas como binarios y el sistema está configurado para arrancar desde cualquiera de las dos áreas. Durante las actualizaciones de software, actualizamos el primer directorio, sincronizamos todo con los medios y verificamos las sumas de verificación MD5 en el disco antes de pasar a la actualización de la segunda copia. Durante el arranque, solo se usan si la suma de comprobación MD5 es buena. Esto garantiza que siempre esté iniciando una imagen coherente.

Answer 2

Dave,

Siempre recomiendo ejecutar el fsck después de varios reinicios, pero no siempre.

La razón es que ext3 está en un diario. Entonces, a menos que habilite la reescritura (sin diario), la mayoría de las veces, su tabla de metadatos / sistema de archivos debe estar sincronizada con sus datos (archivos).

Pero como Jeff mencionó, no garantiza la capa sobre el sistema de archivos. Significa que aún obtienes & Quot; corrupto & Quot; archivos, porque algunos de los registros probablemente no se escribieron en el sistema de archivos.

No estoy seguro de qué dispositivo integrado está ejecutando, pero ¿con qué frecuencia se reinicia? Si se reinicia de forma controlada, siempre puede hacer & Quot; sync; sync; sync & Quot; antes de reiniciar.

He estado usando el CF por años, y en muy raras ocasiones recibí errores del sistema de archivos. fsck ayuda en ese caso.

Y sobre la separación de su partición, dudo de la ventaja de ello. Para cada dato / archivo en el sistema de archivos, hay un metadato asociado con él. La mayoría de las veces, si no cambia los archivos, por ejemplo. archivos binarios / del sistema, entonces estos metadatos no deberían cambiar. A menos que tenga un hardware defectuoso, como cross-talking write & Amp; leer, esos archivos de solo lectura deben ser seguros.

La mayoría de los problemas surgen cuando tienes algo que se puede escribir, e independientemente de dónde lo coloques, puede causar problemas si la aplicación no lo maneja bien.

Espero que eso ayude.