A busy server can have storage requests from a database, log writer, backup process, and several applications waiting at the same time. If those requests target an HDD, their service order changes how far the disk head must move.

Suppose the head is near the middle of a disk. One request needs a nearby track, another needs a track near the outer edge, and a third needs a track near the inner edge. Serving them strictly in arrival order may send the head back and forth across the platters. Reordering them can reduce mechanical movement and complete more useful work in the same period.

A disk scheduling algorithm chooses which pending request an HDD should serve next. Its goals can include:

These goals can conflict. The order with the least movement for the current queue may be unfair to requests that arrive later.

Disk scheduling is a trade-off between mechanical efficiency and waiting-time fairness.

To compare algorithms by hand, we use a simplified HDD with numbered tracks. Some textbooks use the word cylinder because aligned tracks across multiple platter surfaces form a cylinder. For head-movement calculations, both terms act as numbered positions.

Assume:

The distance between two tracks is their absolute difference:

For example:

For a service order containing positions p₁, p₂, ..., pₙ, total head movement is:

This total is a useful proxy for seek work, not an exact latency prediction. Real seek time is not perfectly proportional to track distance, and rotational delay and data transfer time also matter.

The model is still valuable because it makes each algorithm's policy visible.

First-Come, First-Served, or FCFS, processes requests in arrival order.

The queue is:

Starting from track 50, the head follows:

Calculate each movement:

FCFS is simple and preserves arrival order. A request cannot be repeatedly overtaken by newer requests, so starvation is not a concern for a finite queue.

Its weakness is mechanical inefficiency. The example sends the head from one side of the disk to the other several times. A few poorly ordered requests can create a large amount of unnecessary movement.

FCFS can be acceptable when the queue is short, requests are already mostly sequential, or fairness through strict arrival order matters more than reducing seeks. Under a busy random workload, it usually leaves substantial HDD performance unused.

Shortest Seek Time First, or SSTF, chooses the pending request closest to the current head position.

From track 50, the closest request is 43:

After serving 43, the algorithm repeats the decision using the remaining requests. The resulting service order is:

The total movement is:

For this queue, SSTF reduces movement from FCFS's 642 tracks to 208.

The greedy choice

SSTF is a greedy algorithm. It makes the locally cheapest choice at every step without planning the complete route.

That does not guarantee the globally smallest possible movement for every request set. It only guarantees that the next chosen request is the closest one under the algorithm's tie-breaking rule.

If two requests are equally distant, an implementation needs another rule, such as choosing the lower track, choosing the earlier arrival, or continuing in the current direction. A hand calculation must state that rule when a tie affects the result.

Starvation risk

SSTF can make a distant request wait for a long time. Imagine a request at track 190 while a continuous stream of requests arrives near the current head position. Each nearby arrival may look cheaper than traveling to 190.

The far request remains pending even though newer nearby requests keep completing. This is starvation.

The fixed example eventually serves every request because no new work arrives. In a live system, the arrival stream can make SSTF's fairness much worse than the static calculation suggests.

SCAN moves the disk head in one direction, serving requests as it encounters them. When it reaches the physical end of the disk, it reverses direction and continues serving requests.

The behavior resembles an elevator:

The initial direction is essential. In our example, the head begins at 50 and moves toward track 199.

Sort the requests around the starting position:

SCAN first serves the higher requests in ascending order, continues to the boundary at 199, reverses, and serves the lower requests in descending order:

Track 199 is a turnaround point, not a request.

The movement is:

A shorter calculation uses the two sweep segments:

Why SCAN improves fairness

Once the head chooses a direction, requests ahead of it are served as the sweep reaches them. Requests behind it wait for the head to reverse.

Unlike SSTF, a steady stream of nearby requests does not keep the head in one small region forever. The sweep makes progress toward the boundary, giving distant tracks a regular opportunity to be served.

SCAN does not give identical wait times. A request that arrives just after the head passes may wait for the rest of the current sweep and much of the return sweep. Still, its waiting time is generally more predictable than under pure SSTF.

Circular SCAN, or C-SCAN, serves requests while moving in only one direction.

When the head reaches one end, it returns to the opposite end without serving requests during the return. It then begins another service sweep in the original direction.

With the initial direction toward higher tracks, the order is:

The wrap is not a teleport. In the textbook model, movement from 199 to 0 must be counted even though no request is served during that part.

The calculation is:

The sweep-based shortcut is:

Why use a circular sweep?

SCAN serves middle tracks once while moving upward and again while moving downward. As a result, service opportunities are not evenly spaced across all track positions.

C-SCAN treats the disk more like a circular sequence. Every request is served during the same directional sweep. After the head passes a track, a new request at that track waits for the next complete cycle.

This tends to make waiting time more uniform across track positions, but the unserviced wrap adds movement. In this example, C-SCAN moves farther than SCAN.

C-SCAN optimizes for a more consistent service pattern, not necessarily for the smallest movement total.

SCAN always travels to a physical boundary before reversing, even if no request exists near that boundary.

LOOK improves on this behavior by looking at the pending queue. It moves in one direction only as far as the final request in that direction, then reverses.

Starting at 50 and moving upward, the highest pending request is at 190. LOOK reverses there instead of continuing to 199:

The movement is:

The sweep shortcut is:

LOOK retains SCAN's directional progress but avoids traveling through an empty region solely to reach the device boundary. In this example, it saves 18 tracks compared with SCAN:

For the same starting head position, request queue, boundaries, and initial direction, the results are:

SSTF has the smallest total for this particular queue. That does not make it the universally best scheduler. Total movement is only one objective, and the result changes with the request positions and arrival pattern.

The algorithms also make different promises:

A workload that values throughput may prefer fewer seeks. A latency-sensitive multi-tenant system may place more value on preventing one request from being postponed by a continuous stream of others.

Disk scheduling problems can produce different correct-looking totals when their assumptions are incomplete.

Initial direction

SCAN, C-SCAN, and LOOK need an initial direction. Starting toward lower-numbered tracks produces a different service order and movement total than starting toward higher-numbered tracks.

If a problem does not state the direction, the answer must state an assumption before calculating.

Physical boundaries

SCAN and C-SCAN need the lowest and highest valid tracks. In this example they are 0 and 199.

SCAN travels to the boundary before reversing. LOOK reverses at the furthest pending request. Confusing these rules changes the total.

Whether the circular wrap counts

C-SCAN moves from one physical end to the other without servicing requests. That movement still takes time and is normally included in total head movement.

Some diagrams draw the wrap as a curved arrow, which can look instantaneous. It is only a visual convention.

Tie-breaking

SSTF needs a rule when two pending requests are equally distant. Different tie-breaking rules can create different later head positions and therefore different totals.

New arrivals

The worked example uses a fixed queue. A real scheduler makes online decisions while requests arrive and complete.

For FCFS, a new request joins the end. For SSTF, it can become the next request if it is closest. For a sweep algorithm, whether it joins the current pass depends on its location, arrival time, and the scheduler's exact rules.

Static calculations explain the policies, but live behavior depends on the arrival stream.

Adding track distances is useful because seek work is a major HDD cost. It does not capture everything that affects request latency.

Two seeks covering the same number of tracks may not take exactly the same time. The drive also waits for the correct sector to rotate under the head and then transfers the requested bytes. Request size, device firmware, internal error recovery, and queueing delay all contribute.

Total movement also says little about individual waiting time. A schedule can minimize total movement while making one old request wait far longer than all the others.

A complete evaluation therefore asks several questions:

The textbook movement total isolates one important cost so algorithms can be compared cleanly. It should not be mistaken for a full device benchmark.

An SSD has no actuator arm, platter, or seek distance. Reading LBA 190 after LBA 16 does not require a head to cross 174 tracks.

As a result, the central optimization behind FCFS, SSTF, SCAN, C-SCAN, and LOOK does not apply to SSD hardware. Sorting SSD requests by logical address does not eliminate a mechanical delay because there is no mechanical delay to eliminate.

Request ordering can still matter for reasons such as:

Those goals are about concurrency, software overhead, and fairness rather than seek distance.

Modern HDDs also hide their exact physical geometry and can reorder queued commands internally. The operating system's logical block order is therefore an approximation of physical locality, not perfect knowledge of platter placement.

The classical algorithms remain important because they expose the scheduling trade-offs clearly. They also explain why sequential access and request ordering have such a large effect on HDD workloads.

Disk scheduling can reduce the cost of a random HDD workload, but it cannot turn random access into sequential access.

A database performing dependent random reads may keep the queue shallow, leaving little work for a scheduler to reorder. A batch scan can naturally generate nearby requests and spend much more time transferring data than seeking.

When several services share an HDD, a throughput-oriented ordering policy can delay a small request behind a long stream of nearby work. The device may report good aggregate throughput while one service experiences poor tail latency.

Batching and preserving locality help before scheduling begins. Writing related records together or reading adjacent data in larger regions reduces the number of separate seek decisions. A scheduler can then organize the remaining work more effectively.

For SSD-backed services, the same application changes are valuable for different reasons: fewer commands reduce per-request overhead, and concurrency can expose internal parallelism. The mechanical head-movement calculations themselves no longer predict performance.

FCFS serves requests in arrival order but can cause excessive head movement. SSTF greedily chooses the nearest request and often reduces movement, but distant requests can starve. SCAN sweeps to a physical boundary and reverses, while C-SCAN serves in one direction and wraps without service for more uniform waiting behavior. LOOK follows SCAN's directional policy but reverses at the last pending request instead of the disk boundary.

Head movement is calculated by summing the absolute distance between consecutive positions. The result depends on the starting position, request queue, disk boundaries, initial direction, tie-breaking rules, and whether circular wrap movement is counted.

These algorithms model an HDD's mechanical seek cost. They matter far less for SSDs because SSDs have no moving head; SSD scheduling focuses on concurrency, overhead, and latency policy rather than minimizing logical address distance.