Why disk scheduling reduces seek time in Operating Systems - Visual Breakdown

Concept Flow - Why disk scheduling reduces seek time

Requests arrive

↓

Add to queue

↓

Disk scheduler selects next request

↓

Disk head moves to request location

↓

Request serviced

↓

Repeat for next request

Disk scheduling organizes requests to minimize disk head movement, reducing seek time by choosing the next request smartly.

Execution Sample

Operating Systems

Requests = [98, 183, 37, 122, 14, 124, 65, 67]
Head = 53
Schedule = SCAN
# Process requests in order minimizing head movement

This example shows how SCAN scheduling processes disk requests to reduce seek time by moving the head in one direction servicing requests.

Analysis Table

Step	Current Head Position	Next Request Chosen	Seek Distance	Total Seek Time
1	53	65	12	12
2	65	67	2	14
3	67	98	31	45
4	98	122	24	69
5	122	124	2	71
6	124	183	59	130
7	183	37	146	276
8	37	14	23	299

💡 All requests serviced; total seek time is 299 units

State Tracker

Variable	Start	After 1	After 2	After 3	After 4	After 5	After 6	After 7	Final
Head Position	53	65	67	98	122	124	183	37	14
Total Seek Time	0	12	14	45	69	71	130	276	299

Key Insights - 2 Insights

Why does the scheduler choose request 65 after starting at 53 instead of 37?

Because SCAN moves the head in one direction (upwards), it picks the closest request in that direction (65) to reduce back-and-forth movement, as shown in execution_table step 1.

Why is the seek distance between 183 and 37 so large?

After reaching the highest request (183), the head reverses direction to service remaining requests (37), causing a large seek distance, visible in execution_table step 7.

Visual Quiz - 3 Questions

Look at the execution_table, what is the head position after servicing the 4th request?

A 122

B 98

C 124

D 67

💡 Hint

Check the 'Current Head Position' column at step 4 in execution_table.

At which step does the total seek time first exceed 50 units?

A Step 5

B Step 3

C Step 4

D Step 6

💡 Hint

Look at the 'Total Seek Time' column in execution_table to find when it passes 50.

If the scheduler did not use SCAN and picked requests randomly, how would the total seek time likely change?

A It would decrease

B It would increase

C It would stay the same

D It would be zero

💡 Hint

Refer to the concept that SCAN reduces seek time by ordering requests to minimize head movement.

Concept Snapshot

Disk scheduling reduces seek time by ordering requests to minimize disk head movement.
SCAN moves the head in one direction servicing requests in order.
This avoids unnecessary back-and-forth movement.
Result: faster access and less wear on the disk.
Total seek time is sum of all head movements between requests.

Full Transcript

Disk scheduling helps reduce the time the disk head spends moving between requests. When multiple requests come in, the scheduler arranges them to minimize the distance the head travels. For example, the SCAN algorithm moves the head in one direction, servicing requests as it goes, then reverses direction. This reduces back-and-forth movement. In the example, starting at position 53, the head moves to requests 65, 67, 98, and so on, accumulating seek time. The total seek time after all requests is 299 units. This organized approach is faster than random servicing and reduces disk wear.