18 votos

Fsck o no fsck después de 180 días

De forma predeterminada, después de 180 días o algún número de soportes, la mayoría de los sistemas de ficheros Linux de la fuerza de un archivo de system check (comprobación del sistema de ficheros). Por supuesto, esto puede ser desactivado mediante, por ejemplo, tune2fs-c 0-i 0 en ext2 o ext3.

En pequeños sistemas de ficheros, esta comprobación es más que una molestia. Sin embargo, dado grandes sistemas de ficheros, esta verificación puede tardar horas y horas para completar. Cuando los usuarios dependen de este sistema de ficheros para su productividad, dicen que es servir a sus directorios de inicio a través de NFS, sería deshabilitar la fecha programada de la comprobación del sistema de archivos?

Hago esta pregunta debido a que actualmente es de 2:15 am y estoy a la espera de una muy larga comprobación del sistema de ficheros (ext3)!

13voto

Soldarnal Puntos 2646

De los 180 días defecto fsck el tiempo es una solución para el error de diseño que ext3 no admite una línea de verificación de consistencia. La verdadera solución es encontrar un sistema de ficheros que soporta este. No sé si alguno de madurez del sistema de ficheros. Es una verdadera tragedia. Tal vez btrfs nos va a ahorrar un día.

He respondido a la cuestión de la sorpresa de varias horas de tiempo de inactividad de fsck haciendo programada se reinicia con un completo fsck como parte de la norma de mantenimiento. Esto es mejor que correr en corrupción de menores durante las horas de producción, y tener que convertir en una verdadera corte de luz.

Una gran parte del problema es que ext3 tiene una excesivamente lento fsck. Aunque xfs tiene un mucho más rápido fsck, utiliza demasiada memoria para las distribuciones para animar a xfs por defecto en grandes sistemas de archivos. Todavía, en la mayoría de los sistemas de esto es un no-problema. El cambio a xfs iba a permitir al menos razonablemente rápido fsck. Esto puede hacer que correr fsck como parte del mantenimiento normal más fácil programar.

Si usted está ejecutando RedHat y considerando la posibilidad de usar xfs, tienes que tener cuidado de qué tan fuerte que desalentar el uso de xfs y el hecho de que probablemente hay pocas personas utilizando xfs en el núcleo que está ejecutando.

Mi entendimiento es que el ext4 proyecto tiene una meta de al menos cierto grado de mejora de la fsck rendimiento.

4voto

Antoine Benkemoun Puntos 5900

Yo diría que esto es sólo otra razón por la que los servidores de producción no debe correr solo y siempre tienen una caliente/frío de copia de seguridad o tomar parte en un clúster de dos nodos. En estos días de la virtualización, usted puede fácilmente tener un físico servidor principal y un servidor virtual, que es sólo una copia de la física que realiza cada X días, listo para tomar el relevo.

Otros, entonces este no tan útil respuesta, yo diría que debe equilibrar la importancia de los datos... Si esto es sólo un nodo de clúster, vaya. Si se trata de un cliente no soportados servidor web, es posible que desee planificar con anticipación la próxima vez :-)

3voto

f4nt Puntos 504

Depende... Por ejemplo tenemos un servidor bajar para mantenimiento de rutina que se estaba ejecutando una pila de QMail. QMail crea y mata a un montón de archivos como pasa el tiempo, y era un servidor de correo muy ocupado. El fsck tomó unas 36 horas. Es como hemos salvado mucho del rendimiento del trato, pero en definitiva creo que se podría argumentar que el sistema de ficheros era más saludable. ¿Fue realmente vale la pena el caos que se produjo sin embargo? No. A. Todos.

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by: