As I understand it, each file on a Unix-like operating system has an inode number (which can be viewed with "ls -i"), and each inode is a list of disk blocks that contain the actual data of a file.

Is there a Linux command which takes a filename as its argument and prints out the list of disk blocks that that file's inode points to?

P.S. The filesystem in question is ext3.


You could use the "debugfs" tool to view file info on the command line or interactivley. either use:

# debugfs /dev/<spartition>
# stat /path/to/file


# debugfs -R "stat /path/to/file" /dev/<partition>

for example:

# debugfs -R "stat /etc/passwd"  /dev/sda5
Inode: 435914   Type: regular    Mode:  0644   Flags: 0x0
Generation: 979004472    Version: 0x00000000
User:     0   Group:     0   Size: 1577
File ACL: 0    Directory ACL: 0
Links: 1   Blockcount: 8
Fragment:  Address: 0    Number: 0    Size: 0
ctime: 0x4a2d6f78 -- Mon Jun  8 23:07:20 2009
atime: 0x4a2d6f79 -- Mon Jun  8 23:07:21 2009
mtime: 0x4a2d6f78 -- Mon Jun  8 23:07:20 2009
Size of extra inode fields: 4
  • Note that the argument for 'stat' is not always /path/to/file. Using /path/to/file works for files on the root file systems (mounted at /) but not for paths mounted in other file system. In those cases one may get the error message File not found by ext2_lookup. So it is better to use the inode notation for the argument of stat. Use ls -i to get the inode number of a file, then invoke debugfs with that number in '<>' instead of /path/to/file. For example: # debugfs -R "stat <1234567>" /dev/sda2 – ElazarR Feb 14 '17 at 15:14
  • @ElazarR Can you explain that comment? Why should path/to/file not work in all cases? What is confusing to me is that via debugfs ..... /dev/fs_blockdev there is in my comprehension only ever one filesystem in consideration ever, and all those files inside this system can be accessed either via their path or via thair inode, what did you want to express? – humanityANDpeace Mar 10 '17 at 10:56
  • @humanityANDpeace , in the case where a file is in a partition (filesystem) that is outside of the root filesystem, i.e., mounted at some mount point under the root partition, the ext2_lookup operation seems to fail finding the given path under the given device (partition). This results in the error I mentioned. For example, if your /home folders are mounted from /dev/sda5 over the root filesystem (which is on another paritition, e.g., /dev/sda3), then debugfs -R "stat /home/myuser/foo.txt" /dev/sda5 results in an error. But invoking debugfs -R "stat /path/on/rootfs" /dev/sda3 works. – ElazarR Mar 11 '17 at 13:05
  • I think you need sudo, otherwise some unhelpful message will be displayed. – Kedar Mhaswade Jun 25 '17 at 3:54
  • And the converse question: how we can find out which file uses a given block? – Luis A. Florit Jul 5 '17 at 17:28

Look at the syntax for "debugfs", and specifically the "stat" command. That will show you a list of the data blocks used by a file. You can pass parameters to "debugfs" with the "-f" argument to call it from a script.


A simple way to get the list of blocks (without having to read from the partition like in the debugfs answers) is to use the FIBMAP ioctl. I do not know of any command to do so, but it is very simple to write one; a quick Google search gave me an example of FIBMAP use, which does exactly what you want. One advantage is that it will work on any filesystem which supports the bmap operation, not just ext3.

A newer (and more efficient) alternative is the FIEMAP ioctl, which can also return detailed information about extents (useful for ext4).

hdparm --fibmap /path/to/filename

I will not work on zfs, but will on ext4, btrfs, (v)fat, etc

man 8 hdparm :

--fibmap When used, this must be the only flag given. It requires a file path as a parameter, and will print out a list of the device extents (sector ranges) occupied by that file on disk. Sector numbers are given as absolute LBA numbers, referenced from sector 0 of the physical device (not the partition or filesystem). This information can then be used for a variety of purposes, such as examining the degree of fragmenation of larger files, or determining appropriate sectors to deliberately corrupt during fault-injection testing procedures.


At least on some linux machines... "ls -s" might provide what you're looking for.

Edit: my bad, I see that you're looking for a list of the blocks themselves, not a count of them.

  • -s shows the size of the file in blocks -- i want an actual list of the block numbers. – mike Jun 22 '09 at 18:10

e2fsck -b 32768 /dev/hda1 i feel u can try this out or if u looking more docx on the same u can check following


  • That command runs a filesystem check, taking 32768 as a backup superblock. That isn't what he asked for. – James Broadhead Dec 11 '11 at 16:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.