ハードドライブのI/Oに失敗し、ext4パーティションでfsckリカバリを試みた後、「df-i」と「find」によって使用されるiノードの数が大幅に異なるディスクがあります。 。| wc -l ':
[yan@machine ~]$ ls -di /run/media/yan/data
2 /run/media/yan/data
[yan@machine ~]$ lsblk -o NAME,FSTYPE,LABEL,TYPE,SIZE,MOUNTPOINT
NAME FSTYPE LABEL TYPE SIZE MOUNTPOINT
...
sdc disk 1.8T
├─sdc1 vfat clonezilla part 512M
├─sdc2 ext4 live_system part 14.7G
├─sdc3 ext4 system_images part 244.1G
├─sdc4 ext4 data part 781.3G /run/media/yan/data
└─sdc5 ext4 rec part 822.5G
[yan@machine data]$ df -i /run/media/yan/data/
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/sdc4 51200000 74199 51125801 1% /run/media/yan/data
[yan@machine data]$ Sudo find /run/media/yan/data | wc -l
23690
したがって、fsckがパーティションがクリーンであると言っているにもかかわらず(-fを使用しても)、接続されていないiノードがたくさんあるようです。 (74199-23690)欠落しているiノードがどこにあるか知りたいのですが。 photorecを使用して5万個のファイルを取り戻すことができたので、ディスクにまだ残っていることがわかります。
そのため、debugfsを使用しようとしましたが、割り当てられたiノードのリストをダンプする方法がマニュアルのどこにも見つかりません。 (そして、ほとんどのオンライン投稿では、find/ls -iを使用してiノードを一覧表示しますが、私の場合は機能しません)。
df/fsckに従って使用されるiノードのリストを取得する方法を知っている人はいますか?
今のところ、私は次のようなもので非効率的にブルートフォース攻撃を行うことを検討しています。
for i in `seq 1 $NMAX`; do debugfs -R 'ncheck $i' | grep $i; done > inodelist
nMAXは十分に大きいですが、確かにもっと効率的な方法がありますね。
編集:
私は可能な方法を見つけたと思います。 dumpe2fs
すべてのブロックと各ブロックの空きiノードを一覧表示します。それから、使用済みiノードを推測できるはずです。
私はまだ「非フリーiノード」のリストを計算し、それが(少なくともカウント的に)私が望むものであるように見えるかどうかを確認する必要があります。リストから、いくつかの奇妙なiノードが明らかにそれらの間で接続されていることがわかりましたが、ルートには接続されていません:
debugfs: pwd
[pwd] INODE: 45220182 PATH: .../dir1/dir2/dir3/dir4
[root] INODE: 2 PATH: /
debugfs: cd ..
debugfs: pwd
[pwd] INODE: 44957702 PATH: .../dir4/dir1/dir2/dir3
[root] INODE: 2 PATH: /
Ext4ファイルシステムで使用されているiノードのリストを取得する方法を見つけました。どうやら、fsは空きiノードを追跡します(そして、iノードの総数との差によって使用されたiノードの数を推測します)。フリーiノードの範囲はdumpe2fs
から取得できます。使用されるiノードはそのリストを補完するものです(取得するには少しの処理が必要です。それを行うには小さなpythonスクリプトを作成しました)。