SSTF scheduling

Picture yourself at a buffet with dishes spread along a long counter, and a list of dishes you still want. The greedy strategy is simple: always walk to whichever wanted dish is nearest to where you are standing right now, eat it, then again go to the nearest remaining one. You take many short steps instead of one big plan. SSTF scheduling does this for a disk arm: from its current track, it always serves the pending request whose track is closest, minimising the next seek.

Concretely, SSTF stands for shortest-seek-time-first. Among all the I/O requests waiting in the queue, the scheduler picks the one whose target track is nearest to the head's current position, serves it, then repeats from the new position. It is the disk-scheduling cousin of shortest-job-first CPU scheduling: a greedy choice that locally minimises the immediate cost. Compared to plain FCFS, SSTF usually slashes total arm movement, because the arm tends to handle clusters of nearby requests together instead of jumping across the platter.

Why it matters, and its honest flaw: SSTF is a clear improvement over FCFS in average seek time, but it can cause starvation. If requests keep arriving near the head's current location, a request for a far-off track may wait indefinitely — the arm never has a reason to travel out to it. This is the same starvation problem greedy nearest-first policies have everywhere. It is also not optimal: always taking the nearest can leave the arm stranded and force a long trip later. These weaknesses are exactly why the elevator-style SCAN and LOOK algorithms were invented — they sweep steadily so no request is left behind forever.