How Files Find Their Blocks

In this chapter

We'll open up the pointer scheme inside every inode — direct blocks for small files, indirect and double-indirect blocks for larger ones, and the modern extent-based alternative many file systems now use instead — and see exactly how a small, fixed-size record addresses a file of any real size.

8–10 min

The Problem in Real Life

"We know the inode has real pointers to the invoice's actual content," Sarah says, "but I skipped over what that really means. A tiny file and a ten-gigabyte export can't both list every single block by hand in the same small, fixed-size inode."

Mike nods slowly. "So... how does a huge file fit its whole map into one small record?"

A file could be huge. How does a small, fixed-size inode point at all of it?

Mike

A Small, Fixed Record vs. A File of Any Size

Direct pointers cover most real files

A small, fixed number of pointer slots point straight at data blocks — enough for the large majority of ordinary files.

Indirection reaches further, one extra lookup at a time

Indirect, double indirect, and triple indirect blocks trade a bounded number of extra lookups for an enormous addressable size.

An inode is genuinely fixed-size, but a file's actual content can span from a few bytes to many gigabytes, spread across real disk blocks (Act 1's own vocabulary) that don't even need to sit next to each other. The classic real answer is indirection: pointers that point at more pointers, only as deep as a file's own real size actually requires.

Direct blocks — the fast, common case. An inode reserves a small, fixed number of pointer slots (commonly around twelve) that point straight at real data blocks holding the file's actual content. For a small file — most files, in practice — this is the entire map: the inode alone lists every block, and no extra lookup is needed to find any of it.
Indirect blocks — pointers to more pointers. Once a file outgrows its direct pointer slots, the inode's next slot points not at data, but at a real indirect block — itself just a block full of more pointers, each one pointing at an actual data block. This single extra layer multiplies how much a fixed-size inode can address, at the real cost of one extra lookup for those blocks specifically.
Double and triple indirection — for genuinely large files. The same trick nests: a double indirect pointer points at a block full of pointers to indirect blocks, each of which points at more real data blocks; a triple indirect pointer adds one more such layer. Each added layer costs one more real lookup, but multiplies addressable file size enormously — the classic design most people mean by "how a small inode can point at a huge file."
Modern file systems mostly use a different trick: extents. Rather than listing individual blocks one by one (or through the indirection scheme above), many modern file systems store a small number of extents — a real "start block plus a length" pair, describing one whole contiguous run of blocks in a single entry. A file stored in a few large, contiguous runs needs only a few extent entries instead of thousands of individual block pointers — genuinely more compact, and often faster, when the file system can actually keep a file's blocks contiguous.

Direct → indirect → double indirect — reaching further with the same small inode

Inode

~12 direct pointer slots

one extra lookup

Indirect block

a block full of pointers

Data blocks

real file content

Either scheme — indirection or extents — solves the exact same real problem: a fixed-size inode addressing a file of genuinely any size, by trading a small, bounded number of extra lookups for an enormous real increase in addressable content.

Key Takeaway

A fixed-size inode reaches a file of any size the same way a phone's contacts app reaches thousands of numbers from one small screen: not by listing everything directly, but by pointing at more pointers, only as many layers deep as the file actually needs.

Why This Matters

This is the real reason a very large file can be measurably slower to open the first time than a small one, even on the exact same disk — extra indirection layers mean extra real lookups before the actual data is even reached. Understanding it explains genuine, observable performance differences GreenMart's own team might otherwise chalk up to "the disk is just slow."

GreenMart now understands how an inode's small set of pointers reaches a file of any real size — direct blocks, indirect blocks, and (in modern systems) extents. The next chapter turns to a different kind of reliability question entirely: what keeps all of this consistent if the power genuinely cuts out mid-write.