¿Qué pasa con el mensaje de error "estructura necesita borrarse"
El error "la estructura necesita borrarse" es el error que los sistemas de archivos (en particular ext4 y xfs) devuelven cuando detectan un problema de corrupción del sistema de archivos. Desafortunadamente, lo único seguro para reparar la corrupción es desmontar el disco y ejecutarlo e2fsck
en el sistema de archivos. (Técnicamente, no necesitará la -f
opción porque el sistema de archivos ya ha detectado problemas y ha marcado el sistema de archivos como problemático. Por lo tanto, cuando lo ejecute e2fsck
, realizará un análisis completo para solucionar esos problemas y no necesita la -f
opción de forzar un cheque)
Informes de corrupción del sistema de archivos
También debería poder ver los informes de corrupción del sistema de archivos mirando los registros del kernel. (p. ej., ejecutando dmesg
, o mirando /var/log/kern.log
o donde syslog
sea que journald
haya sido configurado para registrar mensajes del núcleo. Debería ver los mensajes que comienzan EXT4-fs error (device sdXX)
. Por ejemplo:
EXT4-fs error (device sda3): ext4_lookup:1602: inode #37005: comm docker: deleted inode referenced: 31872136
También puede ver indicaciones de errores mirando dumpe2fs -h
el sistema de archivos. Campos de interes:
FS Error count: 25
Esto significa que el kernel ha encontrado inconsistencias del sistema de archivos 25 veces.
First error time: Thu Jan 1 12:19:59 2015
First error function: ext4_ext_find_extent
First error line #: 400
First error inode #: 95223833
First error block #: 0
El primer error se encontró el 1 de enero de 2015, a la hora especificada. La función de error y la línea # le permiten identificar exactamente qué parte del código del núcleo encontró el problema. El inodo # le dice qué inodo estuvo involucrado con la inconsistencia del sistema de archivos.
Last error time: Wed Feb 4 11:57:05 2015
Last error function: ext4_ext_find_extent
Last error line #: 400
Last error inode #: 95223833
Last error block #: 0
Esto le indica la última vez que el kernel encontró una inconsistencia en el sistema de archivos. Los grandes deltas entre las dos veces significan que alguien no ha estado escaneando sus mensajes del núcleo. Esto se debe a que cada 24 horas, ext4 registrará mensajes de advertencia de que hay un sistema de archivos con daños, y esos mensajes del núcleo se verán así:
EXT4-fs (dm-0): error count since last fsck: 12
EXT4-fs (dm-0): initial error at time 1441536566: ext4_dirty_inode:4655
EXT4-fs (dm-0): last error at time 1441537273: ext4_remount:4550
Nota: el tiempo está en los mensajes del kernel en número de segundos desde el 1 de enero de 1970 a la medianoche UTC. Puede convertir esto a una hora más legible para los humanos utilizando el comando de fecha, por ejemplo:
% date -d @1441536566
Sun Sep 6 06:49:26 EDT 2015
Qué hacer cuando se da cuenta de que su sistema de archivos está dañado
Realmente no desea ejecutar con inconsistencias del sistema de archivos, ya que eso puede conducir a una mayor pérdida de datos. Realmente es una buena idea saltar sobre estos informes, programar el tiempo de inactividad si es necesario y corregirlos lo antes posible.
¿Por qué me e2fsck
quejé de que el dispositivo estaba en uso después de desmontarlo?
Finalmente, en respuesta a su pregunta: "Corrí fsck
después de desmontar y recibí el siguiente error: ¿ /dev/sdb1 is in use.
Alguna idea?" Eso probablemente se deba a que tiene uno o más procesos en un espacio de nombres de montaje alternativo, y esos procesos todavía se han /dev/sdb1
montado en ese espacio de nombres de montaje. Es posible que desee probar:
grep /dev/sdb1 /proc/*/mounts
Si encuentra procesos que se ejecutan en un espacio de nombres de montaje alternativo, lo más simple es matar y reiniciar esos procesos. (Probablemente sean procesos de daemon). Cuando sale el último proceso que utiliza un espacio de nombres de montaje, el espacio de nombres de montaje desaparece. Y una vez que no haya más espacios de nombres de montaje que se hayan /dev/sdb1
montado, realmente se desmontará de verdad.
La forma de pensar en esto es que umount
actúa como unlink
. Si tiene un archivo con varios enlaces duros, el espacio solo se libera cuando se elimina el último enlace duro. Si tiene varios espacios de nombres activos, cada espacio de nombres actúa efectivamente como un "enlace duro" al soporte en cuestión. Por lo tanto, simplemente desmontar el sistema de archivos en el espacio de nombres de montaje predeterminado no ayudará si algún proceso ha bifurcado el espacio de nombres de montaje predeterminado y se está ejecutando y posiblemente algunos procesos secundarios en esa copia de copia en escritura de su espacio de nombres de montaje principal.
fsck -f
?