Me di cuenta de que XFS no implementa un fsck en el arranque del sistema y una de las razones promocionadas en el registro en diario de los sistemas de archivos ayuda a garantizar que el sistema de archivos esté en un estado coherente después de un cierre impuro; en el siguiente montaje (p. ej., después del reinicio) se vuelve a reproducir el diario.
¿Todavía se necesita un fsck después de un cierre sucio y por qué?
Respuestas:
Estoy respondiendo esto en el contexto general de "sistemas de archivos con diario".
Creo que si se hizo una serie de "paradas no correctas" (por tirar del cable de alimentación o algo así ), tarde o temprano se obtendría a un estado del sistema de archivos que requeriría fscko el equivalente moral de fsck, xfs_repair. El ext4fileystsm en mi computadora portátil en su mayor parte solo reproduce el diario en cada reinicio, se incluyen apagados limpios, pero de vez en cuando, se activa por completo fsck.
Pero pregúntese qué logra "reproducir el diario". La reproducción de un diario solo garantiza que los bloques de disco del resto del sistema de archivos coincidan con el orden que exigen las entradas de diario. Reproducción de un diario equivale a un pequeño fsck, o partes de un completo fsck.
Creo que está sucediendo un juego de manos verbal: reproducir una revista hace parte de lo que fsckhace tradicionalmente , y xfs_repaires exactamente lo que es el mismo tipo de programa que e2fs.fsck(o cualquier otro sistema de archivos fsck). La gente de XFS acaba de creer o su experiencia los llevó a no ejecutarse xfs_repairen cada arranque, solo a reproducir el diario.
fsckno es 'pedante'. Convertí una ext3 LVMpartición ext4y comencé a recibir errores 'ext4_mb_generate_buddy' debido, según tengo entendido, a un error en el ext4código que causó una falta de coincidencia en las copias en disco y en memoria del mapa de bits en las particiones convertidas 'LVM'. Por lo que puedo decir fsck, no ocurrió corrupción. La solución fue desactivar la UNINIT_BGopción o mover los datos y reinicializar la partición como ext4; Tomé el último curso. ¡Pero sigo pensando que fsckvale la pena perder unos minutos esperando un dato!
ayudar a garantizar que el sistema de archivos esté en un estado consistente después de un cierre sucio
Lo primero que se debe tener en cuenta es que XFS, reiser y la mayoría de las configuraciones de ext solo implementan el registro de metadatos, que consiste en evitar fsck. El diario no siempre se reproduce al inicio; puede descartarse si está incompleto.
Hay sistemas que admiten el registro de datos completos, pero en la práctica el nivel de seguridad que estos brindan sobre el registro de metadatos es muy pequeño en escenarios del mundo real.
Entonces, un "estado inconsistente" y los problemas solucionados por fsck son desajustes entre los metadatos y los archivos mismos. Para evitar esto, el sistema operativo escribe los cambios de metadatos propuestos en el diario, luego escribe los datos reales en el disco, luego aplica los cambios de metadatos que se replican en el diario en el disco. El único inconveniente con esto es que el controlador de disco almacenará en búfer y potencialmente reordenará las solicitudes. Para evitar esto, la mayoría de los sistemas de archivos de diario implementan barreras: separan cada operación y esperan que el disco reconozca que ha completado la operación. Pero muchos discos modernos en realidad reconocen la finalización de las escrituras antes de que se confirmen los datos. Por lo tanto, las cosas pueden ponerse desordenadas.
¿Todavía se necesita un fsck después de un cierre inmundo y por qué
La mayoría de los sistemas de archivos mantienen un recuento de montaje: una vez que se alcanza este recuento, se activará un fsck completo en el próximo intento de montar el disco. La razón es que los datos del disco pueden estar dañados incluso cuando no se está escribiendo explícitamente, incluso sin errores en el software. El comentario anterior de psusi está mal.
hdparm -W), el disco no completa las solicitudes de escritura hasta que esté en el medio. ¿Por qué crees que existe esa opción? Las barreras evitan el reordenamiento cuando se emiten múltiples solicitudes. Sin barreras, el fs simplemente no emite más solicitudes hasta que las anteriores se hayan completado, manteniendo así el orden sin barreras ... siempre que la caché de escritura en disco no esté habilitada. El propósito de las barreras es permitirle habilitar la caché de escritura, sin corromper el fs en un bloqueo.
sync. Déjame intentar de nuevo. El procedimiento para escribir en el disco sin barreras es escribir en el diario, syncvaciando así cualquier caché de escritura y luego escribiendo los datos reales. Esto asegura que el diario siempre se pueda usar para recuperar el fs después de un bloqueo, pero la sincronización ralentiza las cosas y derriba a medias el propósito de la caché de escritura. Por lo tanto, se agregaron barreras como un mejor reemplazo y sync, con el soporte de disco adecuado, pueden reclamar con seguridad gran parte del rendimiento que quita la sincronización.
No es necesario fsck un sistema de archivos de registro en diario simplemente debido a un cierre impuro.
La razón completa para soportar la penalización del rendimiento en tiempo de ejecución del registro de metadatos es asegurarse de que el sistema de archivos pueda volverse 100% consistente nuevamente al reproducir automáticamente el registro de metadatos en el siguiente montaje, si el sistema de archivos no se desmontó limpiamente.
El único papel de fsck es garantizar la coherencia de los metadatos, por lo que es redundante ejecutar fsck simplemente porque el sistema de archivos no se desmontó correctamente.
Sin embargo, un sistema de archivos de registro en diario puede corromperse por otras razones: falla de hardware, errores de controladores, errores de administración, etc., por lo que las herramientas fsck son ciertamente necesarias. Simplemente no hay razón para invocarlos únicamente debido a un cierre impuro.