
1 Disco duro que alberga 4 sistemas de archivos EXT4, llamémoslos A (1,2,3,4), cada uno de ellos tiene una entrada en mi fstab pero rara vez se monta, la unidad incluso se apaga a través de udiskctl en el momento del inicio.
1 Disco duro que alberga 8 sistemas de archivos EXT4, cada uno de ellos con una entrada en mi fstab, 4 de ellos, digamos B(1,2,3,4) se montan automáticamente en el momento del inicio, los otros cuatro, digamos C( 1,2,3,4) que se montan ocasionalmente según demanda.
En estas condiciones (A(1,2,3,4) no montado y la unidad asociada apagada; ninguno de los sistemas de archivos C(1,2,3,4) montado) y por cualquier motivo (fallo de energía, pánico en el kernel, disco duro). restablecer...) el sistema no se apaga normalmente.
En el próximo reinicio, se verificará cada uno de estos sistemas de archivos.
Todos los sistemas de archivos que no se montaron en un momento de apagado anormal se dicen rápidamente limpios:
P1:¿Está esta conclusión impulsada por la única lectura de la situación de la supermanzana?s_estadocampo o se realizan otras comprobaciones?
P2:¿Depende de las razones que desencadenaron el apagado anormal, del hecho de que la unidad subyacente estuviera encendida o no?
P3:¿Estas comprobaciones ordenarán a fsck que monte el sistema de archivos?
P4:Si bien estos estados de limpieza se informan en la consola, ¿por qué no puedo encontrar estos informes reflejados en los registros de mi kernel (o cualquier otro) mientras que los rastros de los sistemas de archivos que realmente necesitaban reparación y eventualmente recuperación del diario sí lo están?
Bajo Linux-5.4 / e2fsck 1.46.5 /openrccomo sistema de inicio ymetalologoactuando como demonio syslog si eso importa.
Reglas más relevantes de metalog:
Kernel messages :
facility = "kern"
logdir = "/var/log/kernel"
break=1
Fallback:
facility = "*"
minimum = 6
logdir = "/var/log/fallback"
Respuesta1
Por favor, no hagas varias preguntas.
Cuando se edita una partición mount
, el código del sistema de archivos copia las tablas de asignación de bloques de la partición en la memoria y marca las tablas del disco como "necesitan recuperación".
El código del sistema de archivos gestiona la asignación de bloques a la velocidad de la memoria, que es MUCHO más rápida que la velocidad del disco.
Periódicamente, las tablas en memoria se vuelven a escribir en el disco, tanto para mantenerlas relativamente actualizadas como para evitar la necesidad de mantenerlas todas en la memoria a la vez.
Cuando se edita la partición umount
, las tablas en memoria se escriben en el disco (borrando el indicador "necesita recuperación"). Las tablas en memoria se descartan.
Cuando el sistema falla, las tablas actualizadas en memoria se pierden y el indicador "necesita recuperación" todavía está configurado en el disco.
Si el sistema de archivos es necesario para el arranque ( /etc/fstab
la entrada tiene auto
), y el indicador "necesita recuperación" está configurado en el disco, fsck
se ejecuta un sistema de archivos específico (por ejemplo, fsck.ext4
para ext4
sistemas de archivos) para "recuperar" el sistema de archivos; haga que las tablas de asignación de bloques sean "correctas". " (minimizar la pérdida de datos, garantizar que ningún bloque esté libre ni utilizado, ...), preservar los bloques que se escribieron mientras "necesita recuperación", etc. Dado que fsck
está creando sus propias tablas, es posible que el disco no se pueda mount
editar, y Además, el disco tiene el indicador "necesita recuperación" configurado hasta que fsck
tenga éxito.
Esta actividad previa al montaje causada por el sistema fsck
tiene lugar antes de que el proceso de arranque esté lo suficientemente "activo" como para registrar realmente los mensajes, pero intente dmesg
.
Gracias LustreOne,
En el momento del montaje, e2fsck verificará tanto el indicador de "necesita recuperación" del diario como también realizará una verificación básica de los bloques de superbloque y descriptor de grupo que necesita para montar el sistema de archivos. Si se establece "necesita recuperación", se reproducirá el diario. Si se encuentran otros errores, ejecutará un e2fsck completo del sistema de archivos. – LustreOne