Before you can read the parent note and follow every line, you need to own a handful of symbols and pictures. This page builds each one from absolutely nothing, in an order where each idea leans on the one before it. Nothing here is assumed — if the parent used it, we define it here.
Picture a shiny circular platter, like a tiny record. Data is not written randomly on it — it lives on concentric rings, one inside the other, like the rings you see when you cut a tree trunk.
The picture: each ring in the figure is one cylinder. The innermost ring is cylinder 0; they count outward.
Why the topic needs it: the entire game is moving between rings. If there were no rings — if data were one blob — there would be nothing to schedule. See Hard Disk Drive structure (cylinders, tracks, sectors) for the full anatomy.
We give every ring a whole number so we can do arithmetic on positions.
The picture: unroll the rings into a straight number line — a ruler laid from 0 on the left to 199 on the right. Every request is now just a dot on that ruler. This "flatten the rings into a line" trick is the single most important visual of the whole topic.
Why the topic needs it: once rings are numbers on a line, "how far did the head move?" becomes plain subtraction. That is what makes the whole subject computable.
The picture: on the number-line, the head is a single marker sitting on one dot. To serve a request elsewhere, the marker must walk along the line to that dot — it cannot teleport (except in C-SCAN's return jump, which is still a real physical sweep).
Why the topic needs it: there is only one head. It cannot be in two places at once, so requests must be served in some order, one after another. That constraint is the entire reason "scheduling" exists.
The parent note writes things like h0→h1→⋯→hn. Let us earn every piece.
The picture: on the number line, drop a labelled flag at each stop in the order the head reaches them: flag h0 at the start dot, then h1, h2, … A different algorithm simply plants the same flags in a different order.
The parent's core formula is stuffed with vertical bars, ∣hi−hi−1∣. Here is what they mean, from zero.
Why we need it here — the WHY of choosing this tool: the head moving from cylinder 124 down to 65 covers 124−65=59 cylinders. But moving from 65up to 124 gives 124−65=59 too — wait, but 65−124=−59. A negative distance is meaningless for physical travel; the arm slides 59 cylinders either way. Absolute value is exactly the tool that says "I care how far, not which way." We chose it (not plain subtraction) precisely because direction must be discarded when totalling travel.
The picture: each step of the head is a coloured segment on the number line. ∑ just means lay all those segments end to end and measure the total length.
Read it bottom to top as a build: rings → numbers → a line → a moving marker → an order of stops, plus the distance and sum tools, plus direction and edges — all feeding the single quantity total head movement, which is what every algorithm in the parent note competes to shrink.
The why-it's-slow half of the story lives in Seek time vs Rotational latency — this page counts cylinders; that page turns cylinders into milliseconds.
The "many requests waiting, pick an order" pattern is the same one behind Process Scheduling — FCFS, SJF, Round Robin and the greedy cousin SSTF (Shortest Seek Time First).
Why a fair order matters at all: Starvation and Fairness in OS.
Where these requests come from in the first place: I/O Subsystem and Device Drivers.
