Solución 1:
El tiempo de fsck predeterminado de 180 días es una solución para la falla de diseño de que ext3 no admite una verificación de coherencia en línea. La solución real es encontrar un sistema de archivos que admita esto. No sé si algún sistema de archivos maduro lo hace. Es una verdadera tragedia. Quizás btrfs nos salve algún día.
Respondí al problema del inesperado tiempo de inactividad de varias horas de fsck realizando reinicios programados con un fsck completo como parte del mantenimiento estándar. Esto es mejor que encontrarse con corrupción menor durante las horas de producción y que se convierta en una interrupción real.
Una gran parte del problema es que ext3 tiene un fsck excesivamente lento. Aunque xfs tiene un fsck mucho más rápido, usa demasiada memoria para las distribuciones para fomentar xfs por defecto en sistemas de archivos grandes. Aún así, en la mayoría de los sistemas esto no es un problema. Cambiar a xfs al menos permitiría un fsck razonablemente rápido. Esto puede facilitar la programación de la ejecución de fsck como parte del mantenimiento normal.
Si está ejecutando RedHat y está considerando usar xfs, debe tener cuidado con lo fuertemente que desaconsejan el uso de xfs y el hecho de que probablemente haya pocas personas que usen xfs en el kernel que está ejecutando.
Tengo entendido que el proyecto ext4 tiene el objetivo de al menos mejorar un poco el rendimiento de fsck.
Solución 2:
Diría que esta es solo otra razón por la cual los servidores de producción no deben ejecutarse solos y siempre tener una copia de seguridad en caliente/frío o participar en un clúster de dos nodos. En estos días de virtualización, puede tener fácilmente un servidor principal físico y un servidor virtual, que es solo una copia del físico hecho cada X días, listo para tomar el control.
Aparte de esta respuesta no tan útil, diría que debe equilibrar la importancia de sus datos... Si esto es solo un nodo de clúster, omítalo. Si este es el servidor web sin copia de seguridad de un cliente, es posible que desee planificar con anticipación la próxima vez :-)
Solución 3:
Depende... Por ejemplo, tuvimos un servidor fuera de servicio por mantenimiento de rutina que estaba ejecutando una pila de QMail. QMail crea y elimina muchos archivos a medida que pasa el tiempo, y era un servidor de correo muy ocupado. El fsck tardó unas 36 horas. No es que hayamos ahorrado mucho rendimiento con el trato, pero en última instancia, supongo que podría argumentar que el sistema de archivos era más saludable. ¿Realmente valió la pena el caos que siguió? No. A. Todos.