file-system layers

Think of how a letter gets from your hand to a friend across the country. You write words on paper, drop it in a box, the post office sorts it into routes, trucks carry sacks of mail, and finally a carrier walks it to a door. Each stage knows only its own job and trusts the stage below it. A file system is built the same way: turning the friendly idea of a named file into actual marks on a disk happens through a stack of layers, each one a little closer to the bare hardware.

From top to bottom, the classic layers are: the logical file system, which knows about file names, directories, permissions, and the per-file metadata record (the file control block); the file-organization module, which knows that a file is a sequence of logical blocks and maps each logical block number to a physical block number on the disk, and which also tracks free space; the basic file system, which issues plain commands like read or write physical block number 0x4F2 to and from the device; and the I/O control layer (device drivers and interrupt handlers) that actually talks to the disk controller. So a request like read the 3rd block of report.txt travels down: the logical layer finds the file's metadata, the organization module turns logical block 3 into physical block 1574, the basic file system says fetch block 1574, and the driver makes the hardware do it.

Why build it in layers at all? Because each layer can be written, tested, and replaced on its own, and the upper layers do not have to care whether the storage is a spinning disk, an SSD, or a file over the network. The cost of layering is a little overhead and some duplication, but the gain in clarity and reuse is enormous — the very same basic file system and I/O code can sit under many different on-disk formats.