§41.1–41.3The Problem, and FFS's Cylinder Groups

Part III OSTEP pp. 511–514 · ~7 min read

  • fast file system
  • cylinder
  • cylinder group
  • block group

The old UNIX file system was beautifully simple — one superblock, an inode region, and the rest data:

SInodesDatadata blocks often far from their inode → seek on every read

It delivered the right abstractions (files and a directory hierarchy), but it had a fatal flaw: it was slow — eventually delivering only ~2% of disk bandwidth.

41.1 The Problem: Poor Performance

The root cause: the old FS treated the disk like random-access memory, ignoring that a disk has real, expensive positioning costs. A file’s data blocks often landed far from its inode, so the common “read the inode, then read the data” pattern paid an expensive seek. And because the free list wasn’t managed for contiguity, the disk grew fragmented — logically sequential files ended up scattered:

The old file system fragmented free space, scattering files across the disk. Files A–E are each 2 blocks; watch what happens to a new 4-block file E. (Colors distinguish files; dashed = free.)
A1A2B1B2C1C2D1D2A B C D — packed

1Four files, nicely contiguous

Start with four 2-block files packed together. Reading any file is a clean sequential access — no seeking.

step 1 / 4

(This scattering is exactly what disk defragmentation tools reorganize away.) A second problem: the 512-byte block was too small for efficient transfer — each tiny block risked its own positioning overhead.

The Crux: How To Organize On-Disk Data For Performance

How can we organize file-system data structures — and what allocation policies do we layer on top — to make the file system disk aware and fast?

41.2 FFS: Disk Awareness Is The Solution

A Berkeley group built the Fast File System (FFS) : same interface (open, read, write, close — so every existing program still worked), but internals redesigned to be disk aware. This move — keep the API, change the internals for performance — is the pattern essentially every file system since has followed.

41.3 Organizing Structure: The Cylinder Group

FFS divides the disk into cylinder groups. A cylinder is the set of tracks at the same distance from the drive’s center across all its surfaces; FFS groups N consecutive cylinders into a cylinder group . Modern drives hide their geometry, so today’s file systems (ext2/3/4) use block groups ( block groups ) — consecutive ranges of the logical block address space — instead:

a cylinder = same-radius tracks across all surfacesblock groups (modern)Group 0Group 1Group 20N= consecutive ranges of the block address space

Groups are the whole trick: put two related files in the same group and accessing one after the other won’t cause a long seek. To make that work, each group is a self-contained mini file system — a superblock copy, its own inode and data bitmaps, an inode table, and data blocks:

SibdbInodesDatacopyevery group is a self-contained mini file system

The superblock is replicated in every group for reliability: if one copy is corrupted, the FS can still be mounted from another.

Aside: How Much Work Is Creating One File?

Creating /foo/bar.txt (one block) touches a lot: write the inode bitmap and the new inode; write the data bitmap and the data block; and update the parent directory foo — its data block (the new entry) and its inode (new length + times). That’s already ~6+ writes to the group, just to make one small file.

Check yourself: the old FS problem and cylinder groups

1.Why did the old UNIX file system perform so poorly (as low as ~2% of disk bandwidth)?

2.In the fragmentation example, why does new 4-block file E end up split across the disk?

3.What was FFS's key move relative to the old file system?

4.What is a cylinder, and what is a cylinder group?

5.Why do modern file systems use block groups instead of true cylinder groups?

6.Why does FFS keep a copy of the superblock in every group?

6 questions