extent-based allocation

Suppose a file occupies a thousand consecutive blocks on disk. You could record this as a list of a thousand block numbers - 50000, 50001, 50002, and so on - but that is wasteful and slow to scan. Or you could record it as a single fact: starts at block 50000, runs for 1000 blocks. That compact span is an extent, and a filesystem that maps files as a handful of extents instead of a long list of individual blocks uses extent-based allocation.

An extent is a triple: a starting logical position within the file, a starting physical block on disk, and a length in blocks. A large, contiguous file might need just one extent to describe gigabytes of data. A file that grew in a few bursts might need a few extents. Modern filesystems (ext4, XFS, Btrfs, NTFS) store these extents in a compact tree inside or hanging off the inode, so the map from file offset to disk block stays small and is searched in logarithmic time. Contrast the older scheme: classic Unix inodes held a list of individual block pointers and, for big files, indirect blocks - extra disk blocks full of pointers to more blocks. Extents replace that per-block bookkeeping with per-run bookkeeping, which is far smaller when files are contiguous.

Why it matters: extents make large files cheap to describe and fast to read, because a few extents can cover an entire movie or database file, and contiguous runs read in long sequential sweeps. The catch is the dependency on contiguity: a badly fragmented file forces many tiny extents, eroding the advantage and bloating the extent tree, which is one reason allocators work hard (delayed allocation, preallocation with fallocate()) to keep files contiguous in the first place.