LOOK and C-LOOK Disk Scheduling

Fixing SCAN's One Remaining Inefficiency

As covered in the previous note, SCAN and C-SCAN both travel all the way to the physical end of the disk, even if no requests actually exist anywhere near that end - genuinely wasted movement. LOOK and C-LOOK fix exactly this specific inefficiency.

LOOK: Reverse as Soon as There's Nothing Left Ahead

Head starts at track 50, moving toward higher track numbers
Request queue: 95, 20, 80, 10   (disk range: 0 to 100)

SCAN would go:  50 -> 80 -> 95 -> 100 (end, wasted) -> 20 -> 10
LOOK instead:   50 -> 80 -> 95 (last actual request - no need to go further) -> 20 -> 10

LOOK behaves exactly like SCAN, except it reverses direction as soon as there are no more pending requests ahead of it in the current direction - it only travels as far as it actually needs to "look" toward, rather than blindly continuing all the way to the disk's physical end.

C-LOOK: The Same Fix, Applied to C-SCAN

Head starts at track 50, moving toward higher track numbers
Request queue: 95, 20, 80, 10

C-SCAN would go:  50 -> 80 -> 95 -> 100 (wasted) -> jump to 0 (wasted) -> 10 -> 20
C-LOOK instead:    50 -> 80 -> 95 (last request) -> jump directly to 10 (first request) -> 20

C-LOOK applies this same principle to C-SCAN: rather than jumping all the way back to the disk's physical start, it jumps directly to the closest pending request on the other side - eliminating both wasted end-of-disk movement and the wasted portion of the return jump.

Why LOOK and C-LOOK Are Generally Considered Strict Improvements

Why This History Is Still Worth Understanding Today

Modern SSDs have no mechanical head to move at all, making these specific algorithms far less relevant to that hardware - but the underlying problem they solve (scheduling requests to minimize wasted physical movement) remains a genuinely important, transferable concept for any system managing access to a physically constrained resource.