A pyramid of memories, not just one
In the memory rung you met the comfortable lie that each process owns a flat expanse of RAM, and you saw the OS keep that lie alive by translating addresses and, when RAM ran out, by quietly setting sleeping pages aside in swap space on disk. But what is that disk, really? And why does RAM itself sit between fast registers and slow storage? This rung answers the questions the memory rung kept pointing past: beneath every byte you name is a physical device with a physical cost, and that cost shapes almost everything an OS does about mass storage.
Computers do not have one kind of memory; they have a whole storage hierarchy, a pyramid. At the very top sit the CPU's registers — a handful of cells the processor reads in a fraction of a nanosecond. Below them is cache, then main memory (RAM), then storage like a disk, then removable or networked storage at the bottom. As you go down the pyramid, three things grow together: capacity gets larger, cost per byte gets cheaper, and — the catch — access gets dramatically slower. The whole craft of the storage hierarchy is to keep the data you are about to touch as high up the pyramid as you can.
Volatile above, persistent below
There is a second line drawn across the pyramid, and it matters as much as speed. Everything from registers down through RAM is volatile: cut the power and it forgets instantly. Everything from disk down is non-volatile, or persistent: pull the plug, come back tomorrow, the bytes are still there. This is exactly why a document you have only edited but not saved vanishes in a crash — your edits lived in volatile RAM, and only a save copies them down to persistent storage. The line between 'fast but forgetful' and 'slow but faithful' is the reason mass storage exists as its own layer at all.
Notice how neatly this dovetails with virtual memory. When the OS pages a process out, it copies pages from fast volatile RAM down to slow persistent disk; when the process touches them again, a page fault pulls them back up. The hierarchy is not a static diagram on a slide — it is a thing the OS is constantly moving data up and down through, all day long, trying to keep what you need now near the top. From here on we stop saying 'the disk' loosely and look at what one actually is.
Cracking open a hard disk
Open a classic hard disk drive and you find something almost mechanical, like a tiny record player. A stack of rigid metal platters spins on a shared spindle, thousands of revolutions per minute. Each platter surface is coated with magnetic material, and data is recorded as magnetized spots along thin concentric rings. A read/write head floats a hair's breadth above each surface on the end of an arm; all the arms move together as one comb. To read a byte, the right head must be over the right ring at the moment the right spot rotates underneath it. That last sentence already contains every reason a disk is slow.
The vocabulary of disk geometry names exactly these parts. One concentric ring on one surface is a track. A track is chopped into fixed-size arcs called sectors — historically 512 bytes each, now usually 4 KB — and a sector is the smallest unit the disk will read or write; you cannot fetch half a sector. The set of tracks at the same radius, stacked straight up through every platter, is a cylinder: all the tracks the head-comb can reach without moving, since the heads move in lockstep. So a physical location on an old disk was once given as a triple: which cylinder, which head (surface), and which sector.
side view of the platter stack top view of one platter
(heads move together, in/out) (it spins under the head)
====[ head ]====> platter 0 .--------. <- outer track
====[ head ]====> platter 1 / ______ \
====[ head ]====> platter 2 | / \ | <- a sector is
^ | | spindle| | one arc of
arm comb moves in / out | \______/ | a track
= SEEK (slow, mechanical) \ /
'--------'
one track, all platters, same radius = a CYLINDER (no seek needed)Why a read takes three different waits
Now picture servicing one request: 'give me the sector at cylinder 800, head 2, sector 17.' The cost breaks cleanly into three parts, and seeing them as three is the single most useful idea about spinning disks. First, the arm comb must slide in or out until the heads sit over cylinder 800. That mechanical swing is the seek time, and because it is a physical object accelerating and stopping, it dominates — typically several milliseconds, an eternity to a CPU. The arm is the slowest, heaviest, most reluctant thing in the whole machine.
Second, even once the head is over the right track, the sector you want is probably somewhere else around the ring — so you must wait for the platter to spin it under the head. That wait is the rotational latency. On average you wait half a revolution; at 7200 RPM a full turn is about 8.3 milliseconds, so the average latency is roughly 4 milliseconds. Third and last, once the right sector is under the head, the bits must actually stream off as the disk keeps turning: the transfer time. For a single sector this is the smallest of the three, often a small fraction of a millisecond.
Add them and you get the total access time: seek + rotation + transfer. The lesson burned into every disk-aware design is that the first two — the moving, waiting parts — usually swamp the third. Reading 4 KB scattered randomly costs almost the same as reading one byte, because you pay the full seek and rotation either way; but reading 4 KB that happen to sit next to each other is wildly cheaper, because you seek and wait once and then just keep streaming. This is the physical root of locality: on a disk, things that are close together are cheap together. The very next guide in this rung takes these three components apart with worked numbers.
Hiding the geometry: logical block addressing
The old cylinder/head/sector triple is a nightmare to program against, and worse, it lies: modern disks pack more sectors on the longer outer tracks than the short inner ones, so the geometry the disk reports is fiction anyway. So drives present a far kinder interface called logical block addressing, or LBA. The OS sees the entire disk as one long, flat array of fixed-size blocks numbered 0, 1, 2, 3, and so on, all the way up. To read, you just ask for 'block number 42,891' — no cylinders, no heads. It is the same gift the memory rung gave you: a simple, linear set of numbers hiding a messy physical reality underneath.
Inside the drive, a small computer called the disk controller keeps the secret map from each logical block number to a real physical spot, and it generally lays consecutive block numbers out physically next to each other. That last point is what lets the OS reason about locality at all: it cannot see cylinders, but it can trust that nearby block numbers are probably nearby on the platter, so reading blocks 100 through 110 in order is cheap. The OS hands a request like read(fd, buf, n) down through the file-system layers until it becomes 'read these logical blocks,' and the controller turns that back into seeks and rotations you never see.
What this rung will build
You now hold the load-bearing facts for everything that follows: a pyramid where speed and persistence trade off, a hard disk whose access cost is seek plus rotation plus transfer, and an LBA interface that turns all that machinery into one flat list of numbered blocks. Guide two takes the three components apart with real arithmetic, so you can predict why one access pattern crawls and another flies. Guide three then asks the obvious follow-up: if seeking is the killer and many requests are waiting, can the OS reorder them to seek less? That is disk scheduling, and you will meet the elevator algorithm — a disk head that sweeps in one direction like a lift serving floors, instead of darting back and forth.
Then the ground shifts. Guide four opens up the SSD, where flash memory has no moving parts and therefore no seek time at all — which both makes everything faster and, surprisingly, makes elevator scheduling nearly pointless, while introducing brand-new problems like erase blocks and wear that disks never had. Finally, guide five steps up a level to RAID: gluing several drives together to go faster (striping), to survive a failure (mirroring and parity), or both — and the honest trade-offs, including the dreaded window while a failed drive rebuilds. Every guide here is the same question asked again: how do we live with storage that is millions of times slower than memory, and sometimes lies, and sometimes dies?