ADVERTENCIA: El sistema de archivos tiene un error. no se pudo arreglar el padre del nodo 47322B43 No se pudo encontrar la entrada del directorio principal.
Tengo el sistema operativo Ubuntu 22.04.2 LTS (Jammy Jellyfish) instalado cada vez que inicio y aparece el siguiente error. Intenté fsck -f /dev/sda2seguir recibiendo estos errores. por favor sugiera cómo arreglar mi sistema
Respuesta1
Primero comprendamos los inodos en términos sencillos.
Al hacer... Nuestro sistema de archivos elegido para esta demostración seráEXT2porque no tiene unllevar un diariomecanismo y por lo tanto será fácil de corromper con el fin de demostrar algunos problemas relacionados con el inodo.
Creemos un archivo de imagen de "disco":
$ truncate -s 10M myfilesystem
Y formatearlo
$ mkfs.ext2 myfilesystem
mke2fs 1.46.5 (30-Dec-2021)
Discarding device blocks: done
Creating filesystem with 2560 4k blocks and 2560 inodes
Allocating group tables: done
Writing inode tables: done
Writing superblocks and filesystem accounting information: done
Observe la cantidad de inodos ... and 2560 inodes... Este es el número máximo permanente para este sistema de archivos en esta partición de disco... Puede crear tantos archivos (todo tipo incluyendo directorios) como ese número (menos los inodos especiales del sistema de archivos) pero no más que ese número en este sistema de archivos.
Creemos un punto de montaje y montemos ese sistema de archivos:
$ mkdir mymount
$
$ mount myfilesystem mymount/
$
$ ls -la mymount/
total 24
drwxr-xr-x 3 root root 4096 May 8 14:24 .
drwxr-xr-x 3 ubuntu ubuntu 4096 May 8 14:29 ..
drwx------ 2 root root 16384 May 8 14:24 lost+found
$
$ df -ih mymount/
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/loop1 2.5K 11 2.5K 1% /home/ubuntu/test/mymount
Observe la cantidad de inodos usados 11... Estos se llaman inodos especiales y están reservados/usados de forma predeterminada para el sistema de archivos con propósitos especiales predefinidos... Usemos algunos más de ellos:
$ touch mymount/file{1..2}
$
$ ls -lai mymount/
total 24
2 drwxr-xr-x 3 root root 4096 May 8 14:33 .
2552 drwxr-xr-x 3 ubuntu ubuntu 4096 May 8 14:29 ..
12 -rw-r--r-- 1 root root 0 May 8 14:33 file1
13 -rw-r--r-- 1 root root 0 May 8 14:33 file2
11 drwx------ 2 root root 16384 May 8 14:24 lost+found
$
$ df -ih mymount/
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/loop1 2.5K 13 2.5K 1% /home/ubuntu/test/mymount
Creamos dos archivos y usamos dos inodos más y terminamos con 11 + 2 = 13.
Liberemos uno de ellos:
$ rm mymount/file1
$
$ df -ih mymount/
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/loop1 2.5K 12 2.5K 1% /home/ubuntu/test/mymount
Son 13 - 1 = 12inodos usados normales y el que acabamos de liberar se reutilizará cuando sea necesario... los inodos son reciclables.
Eso es en condiciones normales... Pero, ¿y sien otro caparazónabrir y utilizar continuamente un archivo:
$ tail -f mymount/file2
-
Luego regrese a nuestro shell original para eliminar ese archivo e inmediatamente desmonte el sistema de archivos sin gracia:
$ rm mymount/file2 && umount -l myfilesystem
$
$ ls -lai mymount/
total 8
6425 drwxr-xr-x 2 root root 4096 May 8 14:29 .
2552 drwxr-xr-x 3 ubuntu ubuntu 4096 May 8 14:29 ..
Luego, móntelo nuevamente:
$ mount myfilesystem mymount/
$
$ ls -lai mymount/
total 24
2 drwxr-xr-x 3 root root 4096 May 8 14:44 .
2552 drwxr-xr-x 3 ubuntu ubuntu 4096 May 8 14:29 ..
11 drwx------ 2 root root 16384 May 8 14:24 lost+found
$
$ df -ih mymount/
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/loop1 2.5K 12 2.5K 1% /home/ubuntu/test/mymount
Observe cómo, aunque el archivo en realidad se eliminó, su inodo no se libera... Esa es una "simulación" de corrupción del sistema de archivos... Desmontemos y verifiquemos:
$ umount myfilesystem
$
$ e2fsck myfilesystem
e2fsck 1.46.5 (30-Dec-2021)
myfilesystem was not cleanly unmounted, check forced.
Pass 1: Checking inodes, blocks, and sizes
Deleted inode 13 has zero dtime. Fix<y>? yes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Inode bitmap differences: -13
Fix<y>? yes
Free inodes count wrong for group #0 (2548, counted=2549).
Fix<y>? yes
myfilesystem: ***** FILE SYSTEM WAS MODIFIED *****
myfilesystem: 11/2560 files (0.0% non-contiguous), 170/2560 blocks
Cerremos el otro shell, montemos nuevamente y verifiquemos:
$ mount myfilesystem mymount/
$
$ df -ih mymount/
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/loop1 2.5K 11 2.5K 1% /home/ubuntu/test/mymount
Ahora ya conoce los conceptos básicos de cómo se utilizan los inodos... Y algo de lo que podría salir mal con ellos para activar una verificación del sistema de archivos y cómo... Lo mismo puede suceder al conectar/desconectar un disco o cuando el sistema pierde energía repentinamente como archivos (especialmente archivos del sistema) son creados/eliminados/actualizados constantemente por procesos del sistema... Es un poco menor en el caso de directorios, ya que normalmente no es posible mantener un directorio abierto mediante un proceso ya que no tienen un identificador como los archivos normales, pero sí corrupción. Puede suceder con los inodos del directorio si lo anterior sucedió mientras se actualizan/modifican sus metadatos y también, aunque es raro, puede suceder cuando el sistema de archivos pierde el acceso a ciertos bloques debido a una unidad de disco defectuosa/deteriorada.
Sin embargo, la mayoría de los problemas con los inodos se pueden solucionar fácilmente y automáticamente mediante utilidades de verificación del sistema de archivos.
Volver a tu pregunta
Sin embargo, hay ocasiones en las que esas utilidades pierden el camino y no saben cómo solucionar un problema con los inodos, especialmente con directorios que no tienen metadatos legibles válidos, ya que entre los métodos que utilizan esas herramientas para solucionar la corrupción con los inodos se encuentra en realidad metadatos. datos que identifican contenidos de directorios, padres…etc.
La captura de pantalla que incluiste hace que me resulte un poco difícil leer y copiar texto de... Sin embargo, lo que parece tener es un inodo 4732284(bajo/usr/src/linux ... /net/ ...) que está etiquetado como un directorio en el sistema de archivos pero carece de los metadatos habituales que describen su relación con sus padres, lo que lo deja huérfano y no ocupa el espacio habitual de un bloque, por ejemplo, 4ksino que ocupa 0espacio y, por lo tanto NULL, ... Mientras está en a la mayoría de los archivos de sistemas de archivos se les permite tener un tamaño nulo/0, los directorios no, consulteesta publicaciónyesta publicaciónpara más detalles.
Este tipo de problema,si no aumenta drásticamente, lo que podría indicar una unidad de disco defectuosa/bloques defectuosos y deteriorados, no es un gran problema y debería ser inofensivo... Para deshacerse de él de manera fácil, sólo necesita usarlo... es decir, crear un archivo en ese directorio y luego eliminarlo para actualizar su metainformación para que funcione. volver a usar un tamaño de bloque completo del sistema de archivos y verse un poco normal... Ese directorio debería ser fácil de detectar ya que mostrará 0el tamaño en la salida de, por ejemplo, ls -lay después de usarlo, debería mostrar el tamaño de bloque habitual, por ejemplo, 4kcomo otros directorios. en el mismo sistema de archivos... Si eso no es suficiente para volver a la normalidad, agítelo más, por ejemplo, configurando su propiedad chown root:rooto cambiando sus permisos, por ejemplo, chmod 755hasta que ls -lamuestre un tamaño distinto al 0de ese directorio.
Luego desmonte el sistema de archivos que lo contiene y ejecute la utilidad de verificación del sistema de archivos nuevamente y esta vez debería solucionarlo.
Eso debería funcionar pero, si no funcionó, entonces tienes dos alternativas...Cualquierausando un depurador del sistema de archivos comodebugfspara arreglar/eliminar la entrada de ese inodo manualmenteoalternativamente, haga una copia de seguridad de sus datos y vuelva a formatear esa partición del disco.