警告: ファイルシステムにエラーがあります。ノード 47322B43 の親を修復できませんでした。親ディレクトリ エントリが見つかりませんでした。
Ubuntu 22.04.2 LTS (Jammy Jellyfish) OS をインストールしていますが、起動するたびに次のエラーが発生します。試してみましたが、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
使用されている 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
2 つのファイルを作成し、さらに 2 つの inode を使用した結果、 になりました11 + 2 = 13。
そのうちの1人を解放しましょう:
$ 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 はリサイクル可能です。
それは通常の状況下での話です...しかし、もし別のシェルでファイルを継続的に開いて使用します。
$ tail -f mymount/file2
-
次に、元のシェルに戻ってそのファイルを削除し、すぐにファイルシステムをアンマウントします。
$ 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
他のシェルを閉じて再度マウントし、確認してみましょう。
$ 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 の破損を修正するために使用する方法の中に、実際にはディレクトリの内容、親などを識別するメタデータが含まれているためです。
あなたが添付したスクリーンショットでは、テキストを読んだりコピーしたりするのが少し難しいです...しかし、あなたが持っているのはinode 4732284（下/usr/src/linux ... /net/ ...）はファイルシステム内でディレクトリとしてラベル付けされていますが、親との関係を記述する通常のメタデータがないため孤立しており、通常の1ブロックのスペースを占有せず、代わりにスペース4kを占有します。ほとんどのファイルシステムでは、ファイルのサイズはnull/0にすることができますが、ディレクトリはそうではありません。0NULLこの郵便受けそしてこの郵便受け詳細については。
この種の問題は、劇的に増加しない場合は、ディスクドライブの故障/不良ブロックや劣化ブロックを示している可能性があります。、大きな問題ではなく、無害なはずです...簡単な方法でそれを取り除くには、それを使用する必要があります...つまり、そのディレクトリにファイルを作成し、それを削除してメタ情報を更新し、完全なファイルシステムのブロックサイズを使用するように戻し、少し正常に見えるようにします...そのディレクトリは、0たとえばの出力にサイズが表示されるため簡単に見つけられるはずですls -la。また、使用後は、4k同じファイルシステム上の他のディレクトリと同様に、通常のブロックサイズが表示されます...それでも正常に戻すのに十分でない場合は、たとえば所有権を設定するかchown root:root、アクセス許可を変更するなどして、そのディレクトリ以外のサイズが表示されるchmod 755までさらに揺さぶります。ls -la0
次に、含まれているファイルシステムをアンマウントし、ファイルシステム チェック ユーティリティを再度実行すると、今度は問題が修正されるはずです。
それは機能するはずですが、機能しない場合は、2 つの選択肢があります...どちらか次のようなファイルシステムデバッガを使用するdebugfsそのinodeのエントリを手動で修正/削除するまたはあるいは、データをバックアップして、そのディスク パーティションを再フォーマットします。