an indirect block

A classic Unix inode is small and fixed-size, but files can be enormous, so the inode cannot possibly hold a direct pointer to every block of a huge file. The trick the early designers used was a clever staircase: keep a few direct pointers for small files in the inode itself, and for bigger files, store a pointer to a whole block that is itself full of pointers. That block-full-of-pointers is an indirect block, and it is how a tiny inode addresses a vast file.

Picture an inode with, say, 12 direct block pointers - enough for a file up to 12 blocks (48 KiB at a 4 KiB block size). Beyond that, the inode also holds one single-indirect pointer: it points at a block which holds nothing but more block pointers (a 4 KiB block fits 1024 pointers, addressing another 4 MiB). Still bigger, a double-indirect pointer points at a block of pointers each of which points at a block of pointers (1024 times 1024 blocks). A triple-indirect pointer adds one more level. Reading a byte deep in a large file may therefore require following two or three pointer blocks from disk before reaching the data - which is exactly why these accesses are slower and why the kernel caches indirect blocks.

Why it matters: indirect blocks are the historical answer to addressing big files with a fixed-size inode, and you will still meet them in ext2/ext3, in many textbooks, and in filesystem-internals questions. Their weakness is real: a large sequential read pays extra disk hops to fetch pointer blocks, and the per-block bookkeeping is bulky. That weakness is precisely what extent-based allocation was invented to fix, which is why ext4 and modern filesystems prefer extents and use indirect blocks only for backward compatibility.