A mechanical arm physically moves to read your data. When ten programs want data at once, the order you serve them changes everything. This page takes you from the hardware up.
Same 8 requests. No hardware change. Just a smarter order — 76% less movement.
START SCROLLING
Step through the machine layer by layer — from the metal casing down to a single sector. Toggle between the 3D view and the top-view platter diagram.
Every time the head moves between tracks, it takes real time. With multiple programs all requesting disk data simultaneously, the OS holds a queue of requests — and the order it serves them determines how far the head travels.
Seek time — the one cost we control
Time for the arm to physically move between tracks. Proportional to distance.
FCFS — NAIVE ORDER — ZIGZAG SEEK PATH
The head zigzags wildly — 183→37 is a 146-track jump that a smarter order would have avoided.
The core problem: serving requests in the wrong order makes the head travel enormous unnecessary distances. Disk scheduling is the OS deciding the right order.
One definition. Nothing more yet.
Disk scheduling is the algorithm the OS uses to decide the order in which pending disk I/O requests are served — with the goal of minimising total head movement.
OPTIMISES
Total seek distance
IGNORES
Rotational latency, transfer time
APPLIES TO
HDDs only — SSDs don't need it
Think of the OS as a dispatcher. The read head is a taxi — it can only be in one place at a time. The dispatcher decides the route through all pending pick-up points to minimise total distance driven.
Every algorithm references these. Know them now, read the rest without friction.
SEEK TIME
Head movement time
Time for the arm to move from one track to another. The dominant cost. |from − to|
REQUEST QUEUE
Pending I/O list
Track numbers that processes have requested but not yet been served. The scheduler reorders this.
STARVATION
A request never served
When a request waits indefinitely because the algorithm keeps choosing others. A serious failure mode.
THROUGHPUT
Requests per unit time
How many I/O requests the disk completes in a given time. More = better performance.
// the example used throughout this page
Head starts at: track 53
Request queue: 98, 183, 37, 122, 14, 124, 65, 67
Disk range: 0 – 199
Each one fixes a specific flaw in the previous. Read them in order.
Rule: Serve requests exactly in the order they arrived. Zero optimisation.
Order: 53→98→183→37→122→14→124→65→67
Rule: From current position, always pick the nearest pending request next.
Order: 53→65→67→98→122→124→183→37→14
Rule: Sweep one direction serving everything; hit the disk edge; reverse.
Order: 53→65→67→98→122→124→183→199 (edge)→37→14
Rule: Like SCAN but stops at the last actual request — no wasted travel to disk edges.
Order: 53→65→67→98→122→124→183→37→14
Rule: One-way sweep only. Jump back to track 0 without serving on return. Uniform wait time.
382 tracks
Rule: Like C-SCAN but jumps to lowest pending request (not track 0). Best of both worlds.
157 tracks
Same 8 requests. Each algorithm. Step through it — the disk arm and track axis move together so you see both representations of the same seek.
Same 8 requests. All 6 algorithms. Side by side.
You've watched the hardcoded example. You know why LOOK beats FCFS by 76%. Now put in your own queue and test your predictions.
Open the disk schedulerNO LOGIN · NO INSTALL · RUNS IN BROWSER