ext4 파일 시스템에서 사용된 inode 목록을 덤프하기 위해 debugfs를 사용하는 방법은 무엇입니까?

하드 드라이브 I/O 오류가 발생하고 ext4 파티션에서 fsck 복구를 시도한 후 "df -i" 및 "find"에 따라 사용된 inode 수가 매우 다른 디스크를 얻었습니다. | 화장실 -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에서 파티션이 깨끗하다고 ​​알려 주었음에도 불구하고 연결되지 않은 inode가 많이 있는 것 같습니다(-f를 사용해도). 누락된 inode가 어디에 있는지(74199-23690) 알고 싶습니다. photorec을 사용하여 50,000개의 파일을 성공적으로 복구했기 때문에 해당 파일이 아직 디스크에 있다는 것을 알고 있습니다.

그래서 debugfs를 사용해 보았으나 매뉴얼에서 할당된 inode 목록을 덤프하는 방법을 찾을 수 없었습니다. (대부분의 온라인 게시물은 inode를 나열하기 위해 find/ls -i를 사용하는데 제 경우에는 작동하지 않았습니다.)

df/fsck를 기반으로 사용된 inode 목록을 얻는 방법을 아는 사람이 있습니까?

현재 저는 비효율적인 무차별 대입 공격을 위해 다음 방법을 사용하는 것을 고려하고 있습니다.

for i in `seq 1 $NMAX`; do debugfs -R 'ncheck $i' | grep $i; done > inodelist

NMAX도 충분히 크지만 좀 더 효율적인 방법이 있겠죠?

편집하다:

가능한 방법을 찾은 것 같아요. dumpe2fs각 블록에 대한 모든 블록과 사용 가능한 inode를 나열합니다. 이를 통해 어떤 인덱스 노드가 사용되었는지 추론이 가능해야 한다.

(적어도 계산 관점에서) 이것이 내가 원하는 것인지 확인하려면 여전히 "자유가 아닌 인덱스 노드" 목록을 계산해야 합니다. 목록에서 분명히 그들 사이에 연결되어 있지만 루트에는 연결되지 않은 이상한 인덱스 노드를 발견했습니다.

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: /