Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It only takes a minute to sign up.
Sign up to join this community
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?
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.
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.
