Scheduling of shared resources is an important O.S. job
In a multiprogrammed system, one of the most important jobs of the operating system is the task of scheduling usage of sharable resources by the various processes.
Disk scheduling
We have already considered the matter of scheduling the CPU. We now turn to the scheduling of disks. This is very important, because most multiprogrammed systems have a common file system that is shared by all the users (even though each may have his own files.)
This file system may reside entirely on a single disk, or it may be spread out over a finite number of disks.
Thus, all processes that do disk IO are competing for access to the same physical disk or set of physical disks. (Note that all processes must do at least one burst of disk IO to initially load a program to run.)
In most cases, any given disk can only perform one access at a time.
Order of service for disk access requests
Thus, if several processes have requested an IO operation on a given disk the operating system must establish some order of service for the requests.
Multiple head disks
The exception to this rule is that some disks have two or more independent head assemblies, and so can service two or more requests at once. However, even in these cases scheduling must be used if there are more requests outstanding than heads available to serve them.
FCFS is simple, but perhaps not the best approach...
Of course, the simplest way to schedule accesses to a disk would be FCFS. But, as we shall see, system throughput can be improved significantly if disk accesses are scheduled in an order that takes into consideration some of the physical characteristics of the disk.
Note: in our discussion we will assume a single disk is being scheduled. In cases where a system has multiple disks, each will be scheduled individually using the same approach we develop here for one disk.
Disks are of two basic types:
Fixed head disks have one head for each track on the disk. These are expensive, but require no head movement time to service a request.
Movable head disks are much more common. They have a single head driven by a stepper motor that can position the head over any desired track on the disk surface.
Movable head timing considerations:
Seek - head movement time - involves two components:
Start/stop time: required whether we move one track or many
Movement time: a function of the number of tracks moved.
Ex: DEC RL02: 15 ms required to move 1 track; 100 ms required to move maximum number of tracks (512).
A rule-of-thumb for average seek time would be 50 ms for a hard disk, 200 + ms for a floppy. But note that seek time depends very strongly on the distance the head moves, and can be zero in the case where two successive accesses are made to the same track.
Search (rotational latency) - average 1/2 rotation time
(e.g. 3000 rpm -> 50 r/sec -> 20 ms/rotation -> 10 ms average search)
Transfer time - some fraction of rotation time.
(e.g. 3000 rpm disk with 100 sectors/track. A transfer of 4 sectors involves 4/100 * 20 ms = 0.8 ms).
Note that seek time is almost always dominant except when the head is already on the correct cylinder.
Fixed head timing considerations
2 & 3 above only. Search is now generally dominant component.
If there are generally < 2 requests for service on a given disk outstanding (as is often the case), this is not much of an issue. We will assume heavy traffic for our discussion.
FCFS: First Come First Served
Simplest approach, always fair, but far from optimal.
Example (from text page 433): 98, 183, 37, 122, 14, 124, 65, 67
Total head movement (assuming we start with head at track 53) is
SSTF: Shortest Seek Time First
Much more efficient, but can lead to starvation.
Example (from text page 434): start the above with head at 53
Total head movement:
But on a heavily used disk SSTF has a problem. If one request is for the extreme outside or inside track, and the other requests are nearer the center, the extreme request can be postponed for a long time or even indefinitely, which is not fair.
SCAN
combines efficiency with fairness.
This algorithm is also known as the elevator algorithm because it works the same way an elevator services requests in a building. When it is going up, it services requests from floors above it (in order), but ignores floors below it. When it is going down, it only services requests below it.
Example (from text page 435):
Total head movement:
Variant: LOOK - we don't go all the way to the extrema of the disk. In the above example, we would turn around immediately after servicing the request at 14, so we would save the 14 units of movement to track 0, and the service to track 65 would involve only 51 tracks - yielding an overall movement of 208.
C-SCAN/C-LOOK: Circular SCAN/Circular LOOK.
This algorithm is similar to SCAN/LOOK except the disk only services requests in one direction and "jumps" to the beginning of the disk when it reaches the last track. This produces a more uniform response time and may be more efficient overall since a single large jump may be faster than several smaller ones. (Note that when it reaches the far end, there will be proportionally fewer requests near where it is because it has just been servicing that end of the disk.)
Total head movement:
Note: C-LOOK does somewhat better compared to LOOK if requests are arriving as it is servicing them, since requests will be denser at the far end of the disk than near where it has just been servicing.
With a fixed-head disk, there is no head movement, so rotational latency becomes the dominant component of access time.
For such disks, we can maintain a (FIFO) queue of requests for each of the sectors. As the disk rotates, we service one request from each queue in turn as each sector goes by. (Note: we may have to skip over a sector each time to allow for delay in starting/finishing each access.)
Example: a fixed-head disk with 8 sectors per track (0..7 are track 0, 8..15 are track, 1 etc.)
Using the same example requests as before, but assuming they are sector numbers, not track numbers, we would get:
| Queue | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
|---|---|---|---|---|---|---|---|---|
| Sector Number |
|
65 |
98 122 |
67 |
124 |
37 |
14 |
183 |
With the head initially at sector 53 (which is part of queue 5), and assuming we can access one sector immediately after we finish its predecessor (a big assumption) our service order would be
so we finish in two rotations (assuming no new arrivals).
Sector queuing can be combined with track ordering on a movable head disk if there are multiple requests for the same track, but this is seldom worthwhile.
$Id: disk_scheduling.html,v 1.3 2000/04/09 03:18:04 senning Exp $
These notes were written by R. Bjork of Gordon College. They were edited, revised and converted to HTML by J. Senning of Gordon College in April 1998.