The gap this rung closes
In the storage rung you saw a disk shed all its mechanical mystery and become one long, flat array of numbered blocks: read block 0, read block 42891, no cylinders in sight. In the file-interface rung you used files and folders from the outside — you called open, read, write on names like report.txt and never once thought about a block number. This rung is the bridge between those two pictures. Somebody has to turn the friendly idea of a named file into actual marks on numbered blocks, and that somebody is the file system: the on-disk data structures, plus the code that maintains them.
The work is layered, exactly like the file-system layers you may already have met. Near the top, the logical layer knows names, folders, and permissions; further down, an organization layer maps a file's logical block 3 to physical block 1574; at the bottom, drivers and interrupts actually move bits to and from the device. This first guide stays mostly at the bottom of that stack, on disk, asking a deceptively simple question: when you format a volume and start storing files, what physical structures get written, and what does each one hold?
A map of the volume
Formatting a volume — what disk formatting really does — is mostly the act of writing down a few fixed structures in a known layout, so that later the operating system can find its way around. Picture the volume, end to end, as a strip of numbered blocks divided into named regions. The very first block (or first few) is reserved as the boot block: a tiny area the firmware reads at startup, holding the bootstrap code that begins loading an operating system. It has nothing to do with your files; it is reserved this way on every volume so the machine always knows where to look first.
Right after the boot block sits the most important record of all: the superblock (Unix's name; the general term is the volume control block). Opening a book, you check the title page and table of contents before reading any chapter — the superblock is exactly that title page for the file system. It holds volume-wide facts: the block size (say 4 KB), how many blocks exist and how many are free, how many inodes exist and how many are free, where the inode table and the free-space maps live, a magic number identifying the file-system type, and flags like whether the volume was cleanly unmounted last time. The moment the OS mounts the volume, almost the first thing it does is read this one record into memory, because every later operation needs these numbers to know where things are and how big the pieces are.
low block numbers ------------------------------------> high block numbers
+--------+------------+-------------+------------+----------------------+
| boot | super- | free-space | inode | data blocks |
| block | block | bitmap(s) | table | (file contents) |
+--------+------------+-------------+------------+----------------------+
^ ^ ^ ^ ^
start- describes which one slot the actual
up code the whole blocks are per file: bytes of your
volume free/used the inodes files & foldersThe inode: your file, minus its name
After the superblock and the maps comes a region called the inode table, and this is where files truly begin. Imagine a library where every book has one index card. The card does not contain the story — it records who wrote it, when it arrived, who may borrow it, and exactly which shelves hold its chapters. The book's name on the spine is separate; it lives in the catalog drawer. In a Unix-style file system that index card is the inode: one small structure per file holding everything about the file except its name and its actual data.
Concretely, an inode stores the file's metadata: its type (regular file, directory, symbolic link, device), its owner and group, its permission bits (the rwxr-xr-x you set with chmod 755), its size in bytes, its timestamps, a link count (how many names point at it), and — the heart of it — the pointers saying which physical data blocks hold the file's contents. How those pointers are arranged is its own deep subject: a handful of direct pointers for small files, then single, double, and triple indirect blocks for larger ones. That is the next guide's story; for now just hold the picture that the inode is the small record from which all of a file's data blocks can be found.
The total number of inodes is usually fixed when the volume is formatted — the inode table is sized once and does not grow. That has a consequence beginners rarely expect: a disk can run out of inodes while it still has free data blocks (millions of tiny files exhaust the table), or run out of space while it still has free inodes. Both feel like 'the disk is full' but they are two different shortages, and only one is fixed by deleting big files.
Where the name lives: directories
If the inode holds everything except the name, then the name must live somewhere — and it lives in a directory. From the user's side a directory is just a folder of named files, but underneath, a directory is itself a file whose contents are a little table mapping each name to an inode number. A directory entry is, at its simplest, just a (name, inode number) pair. So a directory does not contain files; it contains names with the inode numbers those names point to. The inode, found by that number in the inode table, is what actually leads to the data.
Now you can trace what really happens when a program opens report.txt in the current folder. The kernel reads the folder's directory file and scans its entries for the name report.txt; the matching entry gives an inode number, say 1048577; the kernel reads that inode out of the inode table; it checks the permission bits there against who you are; and only then does it follow the inode's block pointers to reach the data. Every path lookup is this same dance — name to inode number to inode to blocks — repeated once per component as you walk down a path like /home/ann/report.txt.
- Read the directory file for the current folder and scan its entries for the name report.txt.
- The matching entry yields an inode number, for example 1048577.
- Read inode 1048577 from the inode table; it holds the type, owner, permission bits, size, and block pointers.
- Check the inode's permission bits against the caller; if allowed, follow its block pointers to read the file's data.
One file, many names
Splitting the name from the inode is not just tidy bookkeeping; it unlocks a real feature. Because a directory entry is only a (name, inode number) pair, two different entries — even in two different folders — can carry the same inode number. Both names then point at one inode, one file, one set of data blocks. That is a hard link: a second name for the very same file, completely equal to the first, not a copy. This is exactly why the inode keeps a link count: it is simply how many names currently point at it.
This reframes what deleting a file even means. Removing a name does not destroy the file — it only removes one directory entry and decrements the link count. The inode and its data blocks are freed only when the link count drops to zero AND no process still has the file open. So deleting one of several hard links leaves the file alive under its other names, and a program can keep reading a file you have already unlinked from every folder, right up until it closes it. The file is really kept alive by its inode, not by any one of its names.
What the rest of this rung builds
You now hold the anatomy that everything else hangs on: a volume that opens with a boot block and a superblock, an inode table where each file is one small metadata record, a directory that maps names to inode numbers, and a free-space bitmap tracking which data blocks are free. Notice that creating even one file already touches several of these structures at once — mark a block used in the bitmap, write the inode, add the directory entry — which quietly plants the seed for the crash-consistency problem we reach at the end of this rung.
The next four guides fill in the pieces this one only named. Guide two asks how an inode actually points at data — the allocation methods: contiguous, linked (and its tidied-up form, FAT), and indexed. Guide three goes deeper into the indexed scheme's indirect blocks and into how the bitmap manages free space. Guide four climbs up to the virtual file system that lets one machine speak ext4, NTFS, and a network share through one set of calls, and to the buffer cache that hides the disk's slowness. Guide five faces the danger we just glimpsed head-on: surviving a crash, through journaling and copy-on-write. Every one of them rests on what you built here — blocks, inodes, names, and the maps that tie them together.