Tenemos una placa personalizada basada en BBB, tiene 256 MB de RAM y 4 GB o eMMC. Estamos usando Linux-3.12 y en eMMC tenemos particiones ext4.
Estoy escribiendo un script que se ejecuta periódicamente y busca errores en el sistema de archivos y, si las particiones no están montadas, intento corregir el error usando e2fsck.
Inicialmente lo usaba e2fsck -n /dev/mmcblk0pN (N is partition number)para verificar si había errores en la partición del sistema de archivos.
Sin embargo, el comando anterior comenzó a dar un resultado incorrecto cuando se montó la partición y se crearon archivos en la partición.
Ahora necesitaba una alternativa para verificar el error del sistema de archivos.
Una opción es usar tune2fs -lel comando en esa partición para verificar el Filesystem statecampo.
Ahora no estoy seguro de si este campo es confiable para verificar errores del sistema de archivos o no. ¿Y qué posibles valores puede tener este campo? He visto sus valores cleany no obtengo más información de la página de manual clean with errors.not clean
Entonces, ¿es tune2fs -l /dev/mmcblk0pN | grep “Filesystem state” | grep “error”confiable detectar errores del sistema de archivos? ¿Alguna otra opción mejor para comprobar los errores del sistema de archivos en la partición?
¿Alguna sugerencia/consejos/información?
Respuesta1
"Tune2fs -l" le indicará si el kernel ha notado problemas de corrupción en el sistema de archivos mientras se está ejecutando. Por ejemplo, si le pide a ext4 que elimine un archivo y ext4 descubre que algunos de los bloques de ese archivo ya estaban marcados como desasignados, eso significa que el mapa de bits de asignación está dañado. Tenga en cuenta que el mapa de bits de asignación ya estaba dañado en el momento en que ext4 lo descubrió. De hecho, podría haber estado corrupto durante días o semanas, y si hubiera estado escribiendo archivos nuevos, es posible que ext4 haya asignado bloques para archivos nuevos que se usaban para archivos más antiguos, y el usuario haya perdido datos como resultado. resultado.
La única manera de decir con certeza si un sistema de archivos es consistente o si puede tener algún grado de corrupción es ejecutar e2fsck en él. Para hacer esto, es necesario desmontar el sistema de archivos o crear una instantánea de solo lectura. (Si está utilizando LVM, puede crear una instantánea de solo lectura, verificar la instantánea de solo lectura y luego, si se descubre que el sistema de archivos está dañado, puede reiniciar el sistema y dejar que e2fsck arregle el sistema de archivos. o envíe un correo electrónico al administrador del sistema para programar un tiempo de inactividad para reparar el sistema de archivos).
Dicho todo esto, si el sistema de archivos se ha dañado, probablemente se deba a un problema de hardware como el caso más común. Es posible que se deba a un error del kernel, aunque periódicamente ejecuto pruebas de regresión en los kernels estables, no solo en los upstream, y no hemos tenido un problema de corrupción de fs en mucho tiempo. Es posible que haya un error de corrupción de memoria en un controlador de dispositivo y que (a) el controlador del dispositivo no esté en el nivel ascendente y el proveedor del hardware no haya realizado un control de calidad adecuado, o (b) el error se haya solucionado en el nivel ascendente. , e incluso se envió al último kernel estable, pero el kernel del dispositivo no recibía actualizaciones de la serie de kernel estable.
Tenga en cuenta que si está buscando ver si se encontró que el sistema de archivos está corrupto porque el kernel tropezó con algo claramente incorrecto, no tiene que simplemente eliminar dmesg o /var/log/messages. También puedes intentar leer el archivo /sys/fs/ext4//first_error_time. Si ese archivo contiene un valor distinto de cero, eso le indicará la hora (usando la época de Unix) en que el kernel detectó una corrupción del sistema de archivos. El archivo errores_count en ese directorio le dirá cuántas corrupciones del sistema de archivos se han detectado (pero eso puede ser simplemente el sistema tropezando con el mismo problema una y otra vez). También es de interés que, si desea probar cómo su sistema maneja los errores del sistema de archivos detectados por el kernel, puede intentar escribir una cadena en el archivo trigger_fs_error --- por ejemplo, echo "test error" > /sys/fs/ ext4/sda1/trigger_fs_error"
Finalmente, eche un vistazo a la perilla de comportamiento de errores que puede configurar en tune2fs. Si realmente desea asegurarse de que no se produzcan más daños después de que se haya detectado un problema de corrupción en el sistema de archivos, es posible que desee configurar el sistema de archivos para que se vuelva a montar como de solo lectura cuando se encuentre un problema. o tal vez simplemente forzar un reinicio, para que e2fsck pueda ejecutarse durante la secuencia de inicio para solucionar un problema antes de que (aún más) datos del usuario se corrompan o se pierdan.