Beyond disk-aware layout, FFS added several smaller innovations — and, just as importantly, several usability features.
41.7 A Few Other Things About FFS
Sub-blocks for small files. Many files were ~2 KB, but 4 KB blocks are great for transfer and terrible for space: a small file could waste half its block to internal fragmentation. FFS introduced sub-blocks sub-block A 512-byte fragment FFS could allocate to a small file so it doesn't waste a whole 4 KB block (internal fragmentation). A file grows in sub-blocks until it reaches a full block, then FFS copies them into one 4 KB block. (Costly copying was mostly avoided by having libc buffer writes into 4 KB chunks.) defined in ch. 41 — open in glossary — 512-byte fragments it could allocate to a small file so it didn’t burn a whole 4 KB block:
As the file grew past 4 KB of sub-blocks, FFS would copy them into a proper
4 KB block and free the sub-blocks. That copying is wasteful, so FFS mostly
sidestepped it by having libc buffer writes and issue them in 4 KB chunks —
avoiding sub-blocks entirely in the common case.
A parameterized, disk-aware layout. On old drives, the CPU had to feed the disk in real time, and a naive consecutive layout lost a full rotation between each block. FFS staggered the layout to match the disk’s timing:
1Standard (consecutive) layout
Blocks laid out 0, 1, 2, … in adjacent sectors. FFS reads block 0; by the time it issues the read for block 1, block 1 has already spun past the head — so it must wait an entire rotation to come back around.
This only reached 50% of peak (you circle each track twice), and modern drives made it obsolete: they read a whole track into an internal track buffer track buffer A small memory inside the drive (a disk cache, historically the track buffer, usually 8–16 MB) that holds data read from or written to the platters — e.g. on reading one sector the drive may cache the whole track to answer later same-track requests quickly. defined in ch. 37 — open in glossary , so the file system no longer has to worry about such low-level timing. Good abstractions win.
Usability features. FFS also introduced things that just made the system
nicer to use: long file names (instead of fixed 8-character names),
symbolic links symbolic link A soft link: a distinct file type whose data is the pathname of another file (ln -s). Unlike a hard link it can cross file systems and point to directories, but if the target is removed it becomes a dangling reference (points to a nonexistent path). Its size equals the length of the stored pathname.
defined in ch. 39 — open in glossary
(aliases that, unlike hard links,
can cross file systems and point to directories), and an atomic rename().
Tip: Make The System Usable
FFS’s deepest idea was disk-aware layout — but its usability features (long names, symlinks, atomic rename) mattered just as much for adoption. Making a system pleasant to use is often as important as its technical breakthroughs.41.8 Summary
FFS was a watershed: it showed that file management is one of the most interesting problems in an OS, and taught the enduring lesson — treat the disk like a disk, respecting its real positioning costs. Hundreds of file systems followed; Linux ext2 and ext3 are direct intellectual descendants, inheriting FFS’s block groups and locality-aware allocation.
Next, we turn from performance to reliability: what happens to all these carefully-placed structures when the system crashes mid-update?
Check yourself: FFS's other innovations
1.What problem do sub-blocks solve, and how?
2.How did FFS mostly AVOID the overhead of sub-block copying?
3.Why did FFS stagger blocks across the track (a parameterized layout)?
4.What made FFS's parameterized (staggered) layout obsolete?
5.Which usability features did FFS introduce, and why did they matter?
6.What is the enduring one-line lesson of FFS?