disk scheduling

Imagine an elevator in a busy building. People on many floors press the button, and a foolish elevator might shoot up to floor 10 for one person, then back to floor 2 for another, then up to floor 9 — exhausting itself running up and down. A sensible elevator instead sweeps in one direction, stopping at every requested floor on the way, then sweeps back. Disk scheduling is exactly that idea applied to a hard disk's read/write arm: when several requests are waiting, in what order should the OS serve them to minimise the arm's back-and-forth travel?

Concretely, on a hard disk the dominant cost of an access is the seek (moving the arm) plus rotational latency. When many I/O requests pile up in a queue, each naming a different track, the order you serve them in determines how far the arm has to travel in total. The disk scheduler reorders the pending queue to shrink that total movement. The simplest policy, FCFS (first-come first-served), just honours request order — fair but wasteful, since it makes the arm dart all over. SSTF (shortest-seek-time-first) always picks the nearest pending track, which cuts movement but can starve far-away requests. SCAN and C-SCAN sweep the arm steadily across the disk like the elevator, and LOOK and C-LOOK do the same but only travel as far as the outermost pending request rather than the disk's physical edge.

Why it matters: on a hard disk, good scheduling can multiply effective throughput, because mechanical movement is so slow compared to actually reading the bits. But here is the crucial modern caveat: on an SSD there is no arm and no seek time, so reordering by track position buys almost nothing — random access is already nearly as fast as sequential. SSDs do benefit from different scheduling (for example, fairness, batching, or not blocking reads behind big writes), but the classic seek-minimising algorithms were built for spinning disks and largely retire when the disk does.