☰

警告：檔案系統有錯誤。無法修復節點的父節點 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

透過這樣做...我們為本次演示選擇的檔案系統將是外部2因為它沒有寫日記機制，因此為了示範一些與 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

注意使用的索引節點的數量11...這些稱為特殊索引節點，預設為檔案系統特殊預定義目的保留/使用...讓我們使用更多的索引節點：

$ 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使用的索引節點，我們剛剛釋放的索引節點將在需要時重新使用…索引節點是可回收的。

這是在正常情況下......但是，如果我們在另一個殼裡連續開啟並使用檔案：

$ 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 損壞的方法實際上是元資料識別目錄內容、父目錄等的資料。

您包含的螢幕截圖使我很難閱讀和複製文字......但是，您似乎擁有的是索引節點4732284（在下面/usr/src/linux ... /net/ ...），它被標記為文件系統中的一個目錄，但是，缺乏描述它與其父級的關係的通常元數據，這使得它成為孤立的，並且它不佔用通常的一個塊空間，例如，4k而是佔用0空間，因此NULL......大多數檔案系統檔案的大小允許為 null/0，目錄則不允許，請參閱這個帖子和這個帖子更多細節。

這類問題，如果它沒有顯著增加，則可能表示磁碟機故障/損壞和損壞的區塊，不是一個大問題，應該是無害的...要以簡單的方式擺脫它，您只需要使用它...即在該目錄中創建一個文件，然後刪除它以更新其元信息，以便它繼續回到使用完整的檔案系統區塊大小並且看起來有點正常...該目錄應該很容易發現，因為它將0在eg的輸出中顯示大小ls -la，並且在使用它之後，它應該4k像其他目錄一樣顯示通常的區塊大小eg在同一個檔案系統上...如果這還不足以使其恢復正常，則可以透過設定其所有權（例如）chown root:root或更改其權限（例如）來進一步調整它，chmod 755直到顯示除該目錄ls -la之外的某個大小。0

然後卸載包含的檔案系統並再次運行檔案系統檢查實用程序，這次應該可以修復它。

這應該可行，但如果不起作用，那麼你有兩個選項...任何一個使用檔案系統調試器，例如debugfs手動修復/刪除該 inode 條目或者或備份資料並重新格式化該磁碟分割區。

技術參考：

相關內容