JOVANA
Explore Library Glossary Getting Started Three Levels Fields How it works Mission
Join the mission
All guides

Seek, Rotate, Transfer: The Cost of a Disk Access

A single read from a spinning disk is really three waits stacked on top of each other. We pull them apart, put real milliseconds on each, work a tiny example, and uncover why a disk is a thousand times happier reading in order than jumping around.

Three waits hiding inside one read

From the previous guide you already know the shape of a hard disk: rigid platters spinning on a spindle, a read/write head riding an arm that swings in and out, and your data laid down on concentric tracks divided into sectors. Now we ask the question that governs almost every storage decision an OS makes: when the drive is told to read one sector, how long does it actually take? The honest answer is that there is no single number — a disk access is three separate delays stacked back to back, and they have wildly different sizes.

Picture it physically. The head is sitting over some track, and you ask for a sector on a different track. First the arm has to travel to the right track — that is seek time. Once the head is parked on the correct track, the sector you want is probably somewhere else around that ring, so you must wait for the platter to spin it under the head — that is rotational latency. Only now, with the head over the right track and the right sector arriving, can the bits actually stream past and be read — that is transfer time. Total access time is simply the sum of the three: seek + rotation + transfer.

ask for one sector  -->  | seek | rotation | transfer | -->  bytes in hand
                            ~9 ms   ~4 ms      ~0.05 ms
                          (move arm)(wait spin)(read bits)

total access time = seek_time + rotational_latency + transfer_time
One read = three waits in a row. The first two dwarf the third, and that imbalance shapes almost everything.

Seek and rotate: the expensive two

Seek time is the arm's journey. Think of a librarian who can only walk straight down one aisle: before she reads a single title she must physically walk to the right aisle, and a hop to the neighbouring aisle is nearly free while a march to the far end of the building takes real time. A short seek to an adjacent track can be well under a millisecond; a full sweep across the platter takes several. Because the arm could be anywhere, drive makers quote an average seek time — for a typical desktop disk, roughly 8 to 12 ms — meaning the seek you would pay over a random distance.

Rotational latency is pure waiting for the spin. The head is now on the right track, but the sector you want has to come around — like a lazy Susan you may grab from only as the dish passes in front of you. If the sector just slipped past, you wait almost a full turn; if it is just arriving, almost nothing; on average, half a revolution. And that average falls straight out of the spin rate. At 7200 revolutions per minute the platter turns once every 60 / 7200 of a second, about 8.33 ms, so the average rotational latency is half of that, about 4.17 ms. This delay is a hard floor: the drive can do nothing but spin until the data arrives, and no cleverness in software erases it.

Transfer: the cheap one (and why size barely matters)

Transfer time is the only part where you are actually reading bits, and it is astonishingly small next to the other two. Once the head is over the right track and the right sector is arriving, the platter is already spinning and the data simply streams past the head as fast as the surface moves. A modern disk transfers on the order of 100 to 200 MB per second, so a 4 KB block takes only tens of microseconds — perhaps 0.02 to 0.05 ms. Set that beside a 9 ms seek and a 4 ms rotation and the lesson is blunt: for a single small read, you spend over 99 percent of your time getting into position and almost none of it reading.

This single fact has an enormous consequence: once you have paid the seek and the rotation, reading MORE is nearly free. Reading one sector and reading the next sixteen sectors on the same track cost almost the same, because the heavy charges (positioning) were one-time and only the tiny transfer grows. That is exactly why sequential access crushes random access on a disk. Reading a megabyte that sits in one contiguous run might cost one seek plus one rotation plus a modest transfer; reading the same megabyte scattered as 256 little pieces all over the platter could cost 256 seeks and 256 rotations — easily a hundredfold slower for the identical number of bytes.

A tiny worked example

Let us put real numbers on a single random read from a 7200 RPM drive, with an average seek of 9 ms and a transfer rate of 200 MB per second. Watch how the total assembles, and how lopsided it is.

  1. Seek: the arm moves to the target track. Average seek = about 9 ms. (Cost so far: 9 ms.)
  2. Rotation: wait for the sector to spin under the head. One turn at 7200 RPM = 60 / 7200 s = 8.33 ms, so average latency = half a turn = about 4.17 ms. (Cost so far: 13.17 ms.)
  3. Transfer: read one 4 KB block at 200 MB/s. Time = 4 KB / 200 MB/s = about 0.02 ms. (Total: about 13.19 ms.)
  4. Read the lesson off the numbers: of the 13.19 ms, the seek and rotation are 13.17 ms — about 99.8 percent — and the actual reading is a rounding error.

Now compare two ways to read 64 KB. As 16 contiguous 4 KB blocks on one track: pay one seek (9 ms) + one rotation (4.17 ms) + transfer of 64 KB (about 0.3 ms) = about 13.5 ms. As 16 blocks scattered randomly: pay 16 full accesses of about 13.19 ms each = about 211 ms. Same 64 KB, same drive, roughly 16 times slower purely because the blocks were not contiguous. Put 13.19 ms in perspective too: in that single random read, a 3 GHz CPU could have executed tens of millions of instructions. That gulf is why the disk sits at the slow bottom of the storage hierarchy, and why the OS works so hard to avoid touching it.

Flat numbers, and where the cost goes

There is a subtlety worth naming honestly. The OS does not actually speak in cylinders, heads, and sectors any more. It asks for blocks by a single flat number through logical block addressing (LBA) — "read 8 blocks starting at LBA 50000" — and the drive's own controller maps that number onto whatever physical geometry currently holds it. So the software cannot directly see seek and rotation at all; it sees only the total time that comes back, and must REASON about the hidden mechanics underneath.

The OS leans on one working assumption to bridge that gap: nearby LBA numbers are probably physically nearby, so consecutive LBAs can usually be read with little or no extra seeking. That is what lets "keep a file's blocks at consecutive LBAs" translate into "read it fast." Be honest about its limits, though: it is a HINT, not a guarantee. Because the controller may silently remap a worn-out sector elsewhere, two consecutive LBA numbers are not always physically adjacent, and a file the OS believes is neatly contiguous can still pay a surprise seek. The model is right far more often than it is wrong, which is exactly why it is useful — but it is a model, not the truth.

And here is the twist that the rest of this rung depends on: every word above is about a SPINNING disk. An SSD has no arm and no platter, so it has no seek time and no rotational latency at all — addressing a flash chip is electronic, the way RAM is. That dissolves the very imbalance we spent this whole guide on: on flash, random access is nearly as fast as sequential, so the elaborate scheduling tricks built to minimise arm movement (the subject of the next guide) buy almost nothing. Keep this cost breakdown firmly in mind, because the following guides are largely the story of OS designs built around it — and of how the SSD quietly knocked the legs out from under several of them.