2

After a hard drive I/O failue and an attempt at fsck recovery on an ext4 partition, I've got a disk where the numbers of used inode is vastly different according to 'df -i' and according to 'find . | 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

So it seems I have a lot of unconnected inodes, despite fsck telling me partition is clean (even with -f). I'd like to know where the (74199-23690) missing inodes are. I know there are still on the disk because I've managed to get back 50k files using photorec.

So I've try to use debugfs, but I can't find anywhere in the manual a way to dump the list of allocated inodes. (And most post online use find/ls -i to list inodes, which won't work in my case).

Does any one know a way to get the list of inodes used according to df/fsck ?

For now, I'm considering to inefficiently bruteforce with something along the lines of :

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

with NMAX big enough, but there is surely more efficient way, no ?

EDIT :

I think I have found a possible way. dumpe2fs list all blocks and free inodes for each block. From it, it should be possible to deduce used inodes.

I still have to compute the list of "non-free inodes" and see if it seems (at least count-wise) to be what I want. From the list, I found some weird inodes apparently connected between themselves, but not to the root :

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: /
Community
  • 1
Yann
  • 211
  • 3
  • 6
  • 1
    You have tagged this with ext4. Is this the type of the filesystem on /dev/sdc4? Can you edit your question to show the output of `ls -li /run/media/yan/data` so we can see the inode number of the mounted directory? The manual page for debugfs mentions `testi`. I suspect you are on the wrong track. The find command will print out one line for each filename, which means that files with multiple names will print out multiple times but only have one inode which will make your *missing* number even worse. Getting files back with photorec doesn't mean that the files were not just deleted. – icarus Nov 12 '16 at 17:10
  • You meant `ls -di /run/media/yan/data`, no ? The inode number of the mounted directory is **2**. How can a file have multiple names ? Through symlinks ? – Yann Nov 12 '16 at 17:31
  • BTW, yes it's a ext4 partition, I have edited the question – Yann Nov 12 '16 at 17:45
  • A file has multiple names due to *hard* links, not symlinks. For example `ls -li /usr/bin/{bunzip2,bzcat,bzip2}` on my system shows me that all three names have the same inode, so this is one file with three names. – icarus Nov 12 '16 at 17:55

1 Answers1

1

I found a way to get the list of used inodes on a ext4 filesystem. Apparently, the fs keep tracks of free inodes (and deduces the number of used inodes by difference from the total number of inodes). Ranges of free inodes can be obtained through dumpe2fs. Used inodes are the complementary of that list (requires a bit of processing to get, I made a small python script to do that).

Yann
  • 211
  • 3
  • 6