3

I would like to know which file occupies a given block on a blockdevice.

The procedure should at least support ext4 on Encrypted LVM, but it would be delicious if it also explained how to do this for other storage systems.

So I am looking for something like:

# whichfile /dev/sda 123456789
/var/log/syslog

And maybe:

# whichfile -v /dev/sda 123456789
Debug: Block 123456789 is in partition /dev/sda6
Debug: /dev/sda6 is part of LVM /dev/kubuntu-vg/root
Debug: /dev/kubuntu-vg/root is LUKS encrypted
Debug: Decrypted device is: /dev/mapper/kubuntu--vg-root
Debug: Block 123456789 on /dev/sda is block 98765432 on /dev/mapper/kubuntu--vg-root
Debug: File system is: ext4
Debug: Block 98765432 contains inode 2345678
Debug: Inode 2345678 is var/log/syslog
Debug: Mount point is: /
/var/log/syslog

Edit:

@Mark Plotnick has a partial solution for going from unencrypted blockdevice to inode. That is one step in the right direction.

Another partial solution: inode -> filename (ext4):

sudo debugfs -R 'ncheck 23456789' /dev/unencrypted_ext4_fs

and more general (slow - but might just work on any inode based file system):

sudo find /mountpoint-for-device -xdev -inum 23456789
Ole Tange
  • 33,591
  • 31
  • 102
  • 198

1 Answers1

0

There is usually no metadata associated to each data block in a file system so in order to implement what you look for, you'll generally need to explore the whole file system(s) that happen to use the partition containing a given block, and analyse each and every file blocks until you find the good one(s).

You'll also need to define what blocks you are referring to, logical, physical, sectors,... (512b, 1k, 4k) and handle special cases like:

  • a block contains parts of more than one file (file systems using fragments like ufs)
  • a block contains a journal so might contain part of one or more files
  • a block is shared by multiple files (deduplicating file systems)
  • a block is shared by different versions of a file belonging to different file systems (snapshots/clone file systems).
  • ...

In any case, you'll need to implement use algorithm for different file systems, and spend some time analyzing their internals.

jlliagre
  • 60,319
  • 10
  • 115
  • 157
  • While this is all true, it brings us no closer to a solution - not even a basic solution that does not take special cases into account. – Ole Tange Jun 25 '17 at 16:48
  • You are right. This should have been a comment but it was a little too long to fit. My point was there can't be a generic, fast, external solution. That should be file system and volume manager specific ones, like the already suggested debugfs or a brute force approach: flush the file cache and fully read each and every file on the file system while monitoring all kernel I/Os with dtrace or similar tools, identify which file is processed when the requested block is read on the target device. – jlliagre Jun 26 '17 at 01:46
  • And my point is: Let us start out with a solution that shows it can be done for a common case, and then we can extend it into special cases later. Do not let perfection be be the enemy of a good-enough solution. – Ole Tange Jun 26 '17 at 04:57