Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

related to: What is a Superblock, Inode, Dentry and a File?

None of the famous metadata structures hold onto to location data for the actual file. Dentry maps names to inodes, and inodes store information about the files -- how does the system know where the file's actual data bits are located on the disk? Is there some sort of default mapping of inode integers to disk location?

share|improve this question
@Tok Would have asked this in a comment on the accepted answer to the linked question, but I don't have the rep and so made it a separate question. –  naftalimich May 1 '13 at 17:07

2 Answers 2

up vote 3 down vote accepted

Given the vast array of file systems out there, I'm certain that exceptions exist, but traditionally, the inode had an array of disk block numbers in it.

For example, in /usr/include/linux/ext3_fs.h, I see a definition of struct ext3_inode.

Inside struct ext3_inode, I see a member i_block[EXT3_N_BLOCKS];/* Pointers to blocks */

Different file systems have had different ways of keeping track of which disk blocks belong to an inode (the on-disk data structure that represents the file's data). Some have an array of block numbers, some have an array of runs or extents, a count plus the beginning block number of a run of contiguous blocks. The Berkeley FFS inode had an array of block numbers, and array of block numbers, each of those blocks contained data block numbers, and a block number that contained block numbers that contained data block numbers.

The whole thing gets a bit weirder for "log structured file systems", but those are the exception rather than the rule.

share|improve this answer
Awesome answer. Thank you for the C. –  naftalimich May 1 '13 at 18:45

If you look in the kernel sources (or a kernel doc package, or on the web), look in Documentation/filesystems, it varies by filesystem.

For example, with ext2 an inode number can be translated using info stored in the superblock to a certain offset in the partition—one of the reasons ext2 allocates a fixed number of inodes at mkfs time—which is then read. The inode contains a lot of metadata, including twelve pointers saying where the actual file data is stored. If there are more than twelve fragments, there is a pointer to an indirect block (which stores a lot more). Indirect blocks can be chained (each has a pointer to the next indirect block).

The superblock is stored at a fixed offset from the start of the partition, so its easy to find. (mkfs creates backup superblocks as well)

You may be interested in the btrfs on-disk format, it even has pictures, though that documentation is less complete than the ext2 docs.

share|improve this answer
Will look into the docs but am trying to navigate the beginning and end of your first paragraph: ..."The inode contains a lot of metadata [...]" Is this after translating it with the superblock info or is this an alternative implementation? –  naftalimich May 1 '13 at 18:22
@naftalimich The superblock gives the parameters which determine the layout of the filesystem (these are set at mkfs time). You can you dumpe2fs to see them. Using those parameters, you can translate an inode number to a position on disk (that stores the actual inode). You can then read the inode (from disk)—that's where that metadata is. An i-number or inode number is an integer that specifies which i-node. A i-node is a data structure. –  derobert May 1 '13 at 20:59
Wow perfect. Most complete answer by far. –  naftalimich May 1 '13 at 22:09

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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