Information Technology Reference
In-Depth Information
requests and then skipping to the outer track and travelling from outer-to-inner
tracks to service three additional requests.
The advantage of CSCAN over SCAN is that if after a pass in one direction,
the disk head were to just switch directions (as in SCAN), it will encounter a
region of the disk where pending requests are sparse (since this region of the
disk was just serviced). Seeking to the opposite side of the disk (as in CSCAN)
moves the disk head to an area where pending requests are likely to be denser.
In addition, CSCAN is more fair than SCAN in that seeking to the opposite
side of the disk allows it to begin servicing the requests that likely been waiting
longer than requests near but \just behind" the head.
Rather than pure seek-minimizing SCAN or SCAN, schedulers also take into
account rotation time and allow small seeks \in the wrong direction" to avoid
extra rotational delays using the rotationally-aware R-SCAN or R-CSCAN -
-Definition: R-SCAN
variations. For example, if the disk head is currently over sector 0 of track 0
0Definition: R-CSCAN
and there are pending requests at sector 1000 of track 0, sector 500 of track 1,
and sector 0 of track 10,000, a R-CSCAN scheduler might service the second
request, then the first, and then the third. Figure 12.4-(c) illustrates the R-
CSCAN algorithm handling a request on the outer track, then one a few tracks
in, then another request on the outer track, and a request near the center on
the arm's rst sweep. The arm's second sweep is the same as for CSCAN.
Example: Effect of disk scheduling.
Question: For the disk described in Figure 12.3, consider a workload con-
sisting of 500 read requests, each of a randomly chosen sector
on disk, assuming that the disk head is on the outside track and
that requests are serviced in CSCAN order from outside to in-
side. How long will servicing these requests take?
Answer: Answering a question like this requires making some educated
guesses; different people may come up with different reasonable
estimates here.
Seek time. We first note that with 500 pending requests spread
randomly across the disk, the average seek from one request to
the next will seek 0.2% of the way across the disk. With four
surfaces, most of these seeks will also require a head switch.
We don't know the exact time for a seek 0.2% of the way across
the disk, but we can estimate it by interpolating between the time
for a 1 track seek (1 ms) and the time for a 33.3% seek (10.5 ms
for reads.) (Disk seek time is not actually linear in distance, but
as we will see in a moment, the exact seek time seems unlikely
to affect our answer much.)
