Es bien sabido que nunca debe fsck una partición montada. Puedo entender cómo esto podría conducir fácilmente a la corrupción si fsck escribe en el sistema de archivos (por ejemplo, se usa la opción -a), pero ¿por qué no se pueden ejecutar verificaciones de solo lectura en discos montados?
Respuestas:
Desde:
http://linux.die.net/man/8/fsck.ext3
"Tenga en cuenta que, en general, no es seguro para funcionar e2fscken sistemas de archivos montados. La única excepción es si el -nse especifica la opción, y -c, -lo -Llas opciones no se especifican. Sin embargo, incluso si es seguro hacerlo, los resultados impresos por e2fsckestán no es válido si el sistema de archivos está montado. Si e2fsckle pregunta si debe verificar si un sistema de archivos está montado o no, la única respuesta correcta es '' no ''. Solo los expertos que realmente saben lo que están haciendo deberían considerar responder esta pregunta en cualquier otro camino. "
El problema básico es que el verificador del sistema de archivos (generalmente) no forma parte del sistema de archivos. En cambio, es un programa separado que lee y escribe en el mismo disco que el código del sistema de archivos en el núcleo. Como resultado, si ejecuta fsck en un sistema de archivos activo, tiene dos entidades diferentes que están leyendo (y posiblemente modificando) los mismos datos (el disco), pero no se coordinan entre sí de ninguna manera. El resultado, como han señalado otros, es que la mayoría de los verificadores esperan que nadie más cambie los metadatos del sistema de archivos mientras se ejecutan. Se confundirán y / o informarán errores espurios si el sistema de archivos del kernel cambia algo que el verificador no espera.
Hay algunos sistemas de archivos con verificadores que están diseñados explícitamente para ejecutarse "en línea" (es decir, mientras el sistema de archivos está activo). Las versiones más recientes de FFS / UFS hacen esto ejecutando fsck contra una instantánea reciente del sistema de archivos (una réplica de solo lectura, punto en el tiempo, copia en escritura). Si encuentra problemas, como inconsistencias en los mapas de bits de asignación, los corrige mediante una llamada al sistema, en lugar de escribirlos en el disco sin formato. Esto le permite coordinarse con el sistema de archivos activo.
El WAFL de NetApp también tiene una herramienta de verificación en línea. Probablemente hay otros.
Ejecutar fsck en una partición de lectura y escritura montada sería una tontería, incluso con fsck en modo de solo lectura. El sistema de archivos cambiará bajo fsck, y los datos en memoria que fsck almacena en caché del sistema de archivos se volverán inválidos (y por lo tanto, fsck verá inconsistencia). Puede ejecutar fsck en un sistema de archivos montado de solo lectura en modo de solo lectura y obtener resultados válidos. Ejecutar fsck en modo de lectura / escritura en un sistema de archivos montado de solo lectura, si fsck realiza cambios en el sistema de archivos durante el curso de su ejecución, el núcleo vería que las estructuras del sistema de archivos cambian inesperadamente debajo de él. Eso también sería malo.
Además del hecho de que probablemente mataría su rendimiento de E / S, si el sistema de archivos se modifica mientras se fsck'd, entonces no hay forma de que fsck pueda realizar un seguimiento de los cambios e informar de las inconsistencias.
Algunos sistemas de archivos como XFS le permiten realizar la comprobación de coherencia mientras el sistema de archivos está montado lectura-escritura, con la advertencia de que probablemente se informarán errores espurios. xfs_checkrecomienda que el sistema de archivos sea desmontado o montado de solo lectura antes de realizar la verificación.
Bueno, el objetivo de fsck es informar inconsistencias del sistema de archivos, es decir, invariantes violados.
Sin embargo, muchos de estos controles involucran más de una estructura FS. Si alguien está modificando el FS (escribiendo datos), estas estructuras pueden estar temporalmente fuera de sincronización. fsck vería esto como una inconsistencia, aunque en realidad no es un problema. fsck no tiene forma de saber si una inconsistencia es temporal o un problema permanente que necesita solución. Por lo tanto, esto no puede funcionar (a menos que un FS esté diseñado específicamente para permitir la verificación en línea. Algunos lo hacen, pero ext3 no).
Puedes hacerlo, así como puedes meter tu mano en una licuadora en movimiento y posiblemente no lastimarte, o igual que puedes saltar desde un edificio alto mientras apuntas al pequeño montón de cojines que colocaste en la acera de abajo.
¿Pero por qué lo harías, además de probar tu propia mortalidad? Porque su jefe seguramente lo probará nuevamente cuando descubra POR QUÉ el servidor de correo no reconocerá la unidad raíz ahora.