Why ordering requests is worth the trouble
Guide 2 left you with one stubborn fact: on a hard disk, the slowest part of an access is moving the arm to the right track, the seek time. Seeking is mechanical — a physical arm swinging across the platter — and it dwarfs the rotational latency and the actual transfer. Now add the real-world twist: a busy machine does not ask for one block at a time. Many processes have outstanding reads and writes, so at any instant the disk has a whole queue of requests waiting, each naming a block somewhere on the platter.
Here is the lever. The arm can only be in one place at a time, and the total time the disk spends is dominated by how far the arm travels in total. The requests have to be served eventually, but you get to choose the order. Choose badly and the arm ping-pongs across the platter, racking up seeks; choose well and it sweeps smoothly, serving many requests with little movement. That choice of order is exactly what disk scheduling is. Crucially, scheduling is free in the sense that matters: it does not read fewer blocks, it just reorders the same work to cut the travel between them.
The naive orders: fair but slow, greedy but unfair
Start with the obvious policy: first-come, first-served (FCFS). Serve requests in the exact order they arrived, like a single queue at a bank teller. It is perfectly fair — no request is ever overtaken — and it is trivial to implement. But fairness ignores geography. If the queue is for blocks 98, 183, 37, 122, 14, 124, 65, 67 and the arm starts at 53, FCFS makes the arm leap to 98, back to 183, all the way down to 37, up to 122, down to 14, and so on. The arm crosses the whole platter several times, because consecutive requests in arrival order are unrelated in space.
The opposite instinct is greed: always serve whichever waiting request is closest to where the arm is now. That is shortest-seek-time-first (SSTF). From 53 it would grab 65, then 67, then 37, then 14, then jump up to 98, 122, 124, 183 — far less total travel than FCFS, because each step is the cheapest available. If SSTF reminds you of the CPU scheduler's shortest-job-first from an earlier rung, that is no accident: it is the same greedy idea, and it inherits the same flaw. A steady trickle of requests near the arm's current position can keep starving a request stuck far out at the edge — the disk equivalent of starvation. The far block waits, and waits, while nearer ones keep cutting in.
SCAN: the disk arm as an elevator
Here is the idea that names this guide. Think about how a building elevator works. It does not greedily rush to whoever pressed a button most recently. It picks a direction — say, up — and keeps going up, stopping at every floor that has a waiting call, until there are no more calls above it. Then it reverses, sweeps down, and serves everyone going the other way. Nobody is starved, because the elevator is guaranteed to come back past your floor on its regular sweep. That is exactly the disk's SCAN algorithm, and that is why it is universally nicknamed the elevator algorithm.
Mechanically, SCAN does this: the arm moves in one direction across the platter, servicing every request it passes, until it reaches the end (the last block); then it reverses and services everything on the way back. Requests are no longer served by arrival or by raw nearness, but by where they fall along the sweep. A request far out at the edge can never starve, because each full sweep is guaranteed to reach the edge and serve it. You have traded SSTF's slightly-shorter total travel for a hard fairness guarantee — and in practice the smooth single-direction sweep is fast anyway, because the arm never doubles back mid-stroke.
Queue (block numbers): 98 183 37 122 14 124 65 67 arm starts at 53, heading UP
0 14 37 53 65 67 98 122 124 183 199
|--------+----+----o----+--+------+--------+---+----------+----------|
start at 53, sweep UP, serving in passing:
53 -> 65 -> 67 -> 98 -> 122 -> 124 -> 183 (reach top end)
then reverse and sweep DOWN:
... -> 37 -> 14
SCAN order: 65, 67, 98, 122, 124, 183, (end), 37, 14
Nobody at the far low end (14) starves: the down-sweep is guaranteed to reach it.Two tweaks: C-SCAN for fairness, LOOK for laziness
Plain SCAN has a subtle unfairness. When the arm reverses at an end, the blocks it just passed get served again very soon on the way back, while the blocks at the far end have waited the longest. So requests in the middle get served roughly twice as often as those at the edges. C-SCAN (circular SCAN) fixes this by treating the platter as a circle: it sweeps in one direction only, serving requests; when it hits the end, instead of reversing it zips straight back to the very start without serving anything on the return, and begins another one-way sweep. Every block now waits about the same amount, because each is visited once per identical, uniform sweep — fairer wait times, at the cost of one long unproductive seek back to the start each cycle.
The second tweak is pure pragmatism. Plain SCAN and C-SCAN march all the way to the physical end of the disk even when there are no requests out there — wasted motion to an empty edge. LOOK (and its circular cousin C-LOOK) simply says: only go as far as the last request in this direction, then reverse (or wrap). The arm 'looks' ahead, sees nothing more pending, and turns around early instead of bumping into the wall. LOOK is almost always what real implementations actually use — it keeps the elevator's fairness while skipping the pointless travel to the rim.
- FCFS — serve in arrival order. Fair, dead simple, but the arm ping-pongs and total seek is huge.
- SSTF — always serve the nearest waiting request. Much less travel, but locally greedy and can starve a far block.
- SCAN (the elevator) — sweep one direction to the end, then reverse. No starvation, smooth single-direction motion.
- C-SCAN — sweep one way only, jump back to the start, repeat. More uniform wait times than SCAN, at the cost of the jump-back seek.
- LOOK / C-LOOK — like SCAN / C-SCAN but reverse at the last request, not the physical edge. The version real disks usually run.
The honest caveat: why this barely matters on an SSD
Everything above rests on one assumption: that physical distance costs time, because there is an arm to move. Pull that assumption out and the whole edifice deflates. On a solid-state drive there is no arm, no platter, no seek — data lives in flash chips reached electronically, and block 14 is no farther away than block 183. With seek time gone, the elevator has nothing to optimize. Reordering requests to minimize arm travel saves you essentially nothing, because there was never any arm travel to save. This is one of the most important honest caveats in storage: the elaborate art of disk scheduling, perfected over decades, barely helps an SSD.
Be careful not to over-correct, though. 'Barely helps' is not the same as 'does nothing.' SSDs still benefit from a different kind of ordering — for example, merging many small adjacent writes into fewer larger ones, and exploiting the device's internal parallelism across chips. So modern operating systems do not just run the classic elevator on SSDs; Linux, for instance, offers schedulers tuned for fast devices (and even a 'none' option that hands ordering straight to the drive's own controller). The headline still holds: seek-minimizing scheduling is a story about spinning rust, and the next guide picks up what actually governs an SSD's behavior instead.