☰

警告：文件系统有错误。无法修复节点 47322B43 的父级，找不到父目录条目

tag-icon • tag-icon boot 22.04 filesystem fsck
警告：文件系统有错误。无法修复节点 47322B43 的父级，找不到父目录条目

警告：文件系统有错误。无法修复节点 47322B43 的父级，找不到父目录条目。

我安装了 Ubuntu 22.04.2 LTS (Jammy Jellyfish) 操作系统，每次启动时都会出现以下错误。我试过fsck -f /dev/sda2仍然出现这些错误。请建议如何修复我的系统 在此处输入图片描述

答案1

首先让我们通俗地理解一下 inode

通过这样做...我们为本次演示选择的文件系统将是EXT2因为它没有日记机制，因此为了演示一些与 inode 相关的问题，很容易被破坏。

让我们创建一个“磁盘”映像文件：

$ truncate -s 10M myfilesystem

并格式化

$ 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

注意 inode 的数量... and 2560 inodes...这是此磁盘分区上此文件系统的永久最大数量...您可以创建任意数量的文件（所有类型，包括目录) 作为该数字(减去文件系统的特殊 inode），但此文件系统上的数量不得超过该值。

让我们创建一个挂载点并挂载该文件系统：

$ 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

注意使用的 inode 数量11...这些被称为特殊 inode，默认情况下为文件系统的特殊预定义目的而保留/使用...让我们使用更多：

$ 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

我们创建了两个文件并使用了两个以上的 inode，最终得到了11 + 2 = 13。

让我们释放其中一个：

$ 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

这是正常13 - 1 = 12使用的 inode，我们刚刚释放的 inode 将在需要时重新使用... inode 是可回收的。

这是在正常情况下...但是，如果我们在另一个 shell 中连续打开并使用文件：

$ tail -f mymount/file2
-

然后回到我们原来的 shell 来删除该文件，然后立即非正常卸载文件系统：

$ 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 ..

然后再次挂载：

$ 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

请注意，虽然文件实际上已被删除，但它的 inode 并未释放...这是一个文件系统损坏“模拟”...让我们卸载并检查：

$ 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

我们关闭另一个 shell 并再次挂载并检查：

$ 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

现在您了解了 inode 的基本使用方法...以及它们可能出现的问题，从而触发文件系统检查以及如何...在插入/拔出磁盘时或系统突然断电时，文件可能会丢失，也可能会发生同样的情况（特别是系统文件) 不断由系统进程创建/删除/更新...目录的情况稍微少一些，因为目录通常不可能由进程保持打开状态，因为它们没有像普通文件那样的句柄，但如果在更新/修改元数据时发生上述情况，目录 inode 可能会损坏，而且，虽然很少见，但当文件系统由于磁盘驱动器故障/损坏而失去对某些块的访问权限时，可能会发生这种情况。

但是，大多数与 inode 相关的问题都可以通过文件系统检查实用程序轻松自动地修复。

回到你的问题

然而，有时这些实用程序会迷失路径并且不知道如何修复 inode 问题，尤其是对于没有有效可读元数据的目录，因为这些工具用来修复 inode 损坏的方法实际上是识别目录内容、父级……等的元数据。

您提供的屏幕截图让我很难阅读和复制文本...但是，您似乎有一个 inode 4732284(在下面/usr/src/linux ... /net/ ...) 在文件系统中被标记为目录，但缺​​少描述其与父级关系的通常元数据，这使其成为孤立文件，并且它不占用通常的一个块空间，例如，4k而是占用0空间，因此NULL...虽然在大多数文件系统上，文件的大小可以为 null/0，但目录则不能，请参阅这个帖子和这个帖子更多细节。

这种类型的问题，如果它没有急剧增加，这可能表明磁盘驱动器出现故障/块损坏或损坏，不是什么大问题，应该是无害的...要轻松摆脱它，您只需要使用它...即在该目录中创建一个文件，然后删除它以更新其元信息，以便它返回到使用完整的文件系统块大小并看起来有点正常...该目录应该很容易发现，因为它将0在例如的输出中显示大小，ls -la并且在使用它之后，它应该显示通常的块大小，例如4k像同一文件系统上的其他目录一样...如果这还不足以使其恢复正常，则通过例如设置其所有权chown root:root或更改其权限等进一步摇晃它，chmod 755直到显示除该目录ls -la之外的其他大小。0

然后卸载包含的文件系统并再次运行文件系统检查实用程序，这次应该可以修复它。

这应该可行，但如果不可行，那么你还有两种选择......任何一个使用文件系统调试器debugfs手动修复/删除该 inode 的条目或者或者备份您的数据并重新格式化该磁盘分区。

技术参考：

相关内容