CS 537
Lecture Notes, Part 9
Disk Scheduling

Contents

A (hard) disk drive record data on the surfaces of metal plates called platters that are coated with a substance containing ground-up iron, or other substances that allow zeros and ones to be recorded as tiny spots of magnetization. Floppy disks (also called “diskettes” by those who think the term “floppy” is undignified) are similar, but use a sheet of plastic rather than metal, and permanently enclose it in a paper or plastic envelope. I won't say anything more about floppy disks, but most of facts about hard disks are also true for floppies, but slower. It is customary to use the simple term “disk” to mean “hard disk drive” and say “platter” when you mean the disk itself.

When in use, the disk spins rapidly and a read/write head slides along the surface. Usually, both sides of a platter are used for recording, so there is a head for each surface. In some more expensive disk drives, there are several platters, all on a common axle spinning together. The heads are fixed to an arm that can move radially in towards the axle or out towards the edges of the platters. All of the heads are attached to the same arm, so they are all at the same distance from the centers of their platters at any given time.

To read or write a bit of data on the disk, a head has to be right over the spot where the data is stored. This may require three operations, giving rise to four kinds of delay.

• The correct head (i.e., the correct surface) must be selected. This is done electronicly, so it is very fast (at most a few microseconds).
• The head has to be moved to the correct distance from the center of the disk. This movement is called seeking and involves physically moving the arm in or out. Because the arm has mass (inertia), it must be accelerated and decelerated. When it finally gets where it's going, the disk has to wait a bit for the vibrations caused by the jerky movement to die out. All in all, seeking can take several milliseconds, depending on how far the head has to move.
• The disk has to rotate until the correct spot is under the selected disk. Since the disk is constantly spinning, all the drive has to do is wait for the correct spot to come around.
• Finally, the actual data has to be transferred. On a read operation, the data is usually transferred to a RAM buffer in the device and then copied, by DMA, to the computer's main memory. Similarly, on write, the data is transferred by DMA to a buffer in the disk, and then copied onto the surface of a platter.

The data on a disk is divided up into fixed-sized disk blocks. The hardware only supports reading or writing a whole block at a time. If a program wants to change one bit (or one byte) on the disk, it has to read in an entire disk block, change the part of it it want to change, and then write it back out. Each block has a location, sometimes called a disk address that consists of three numbers: surface, track, and sector. The part of the disk swept out by a head while it is not moving is a ring-shaped region on the surface called a track. The track number indicates how far the data is from the center of the disk (the axle). Each track is divided up into some number of sectors. On some disks, the outer tracks have more sectors than the inner ones because the outer tracks are are longer, but all sectors are the same size. The set of tracks swept out by all the heads while the arm is not moving is a called a cylinder. Thus a seek operation moves to a new cylinder, positioning each each on one track of the cylinder.

This basic picture of disk organization hasn't changed much in forty years. What has changed is that disks keep getting smaller and cheaper and the data on the surfaces gets denser (the spots used to record bits are getting smaller and closer together). The first disks were several feet in diameter, cost tens of thousands of dollars, and held tens of thousands of bytes. Currently (2006) a typical disk is 3-1/2 inches or 1 inch in diameter, costs a few hundred dollars and holds several hundred gigabytes (billions of bytes) of data. What hasn't changed much is physical limitations. Early disks spun at 3600 revolutions per minute (RPM); currently they spin at about 7200 RPM, or 15,000 RPM for high-performance disks. At 7200 RPM, the rotational latency is at worst 1/7200 minute (8.33 milliseconds) and on the average it is half that (4.17 ms). The heads and the arm that moves them have gotten much smaller and lighter, allowing them to be moved more quickly, but the improvement has been modest. Current disks take anywhere from a millisecond to 10s of milliseconds to seek to particular cylinder.

Just for reference, here are the specs for a popular disk used in PC's and currently selling at the the DoIT tech store for about $300.

When a process wants to do disk I/O, it makes a call to the operating system. Since the operation may take some time, the process is put into a blocked state, and the I/O request is sent to a part of the OS called a device driver. If the disk is idle, the operation can be started right away, but if the disk is busy servicing another request, it must be added to a queue of requests and wait its turn. Thus the total delay seen by the process has several components:

• The overhead of getting into and out of the OS, and the time the OS spends fiddling with queues, etc.
• The queuing time spent waiting for the disk to become available.
• The latency spent waiting for the disk to get the right track and sector.
• The transfer time spent actually reading or writing the data.

Although I mentioned a “queue” of requests, there is no reason why the requests have to be satisfied first-come first-served. In fact, that is a very bad way to schedule disk requests. Since requests from different processes may be scattered all over the disk, satisfying them in the order they arrive would entail an awful lot of jumping around on the disk, resulting in excessive rotational latency and seek time -- both for individual requests and for the system as a whole. Fortunately, better algorithms are not hard to devise.

Shortest Seek Time First (SSTF)

When a disk operation finishes, choose the request that is closest to the current head position (the one that minimizes rotational latency and seek time). This algorithm minimizes latency and thus gives the best overall performance, but suffers from poor fairness. Requests will get widely varying response depending on how lucky they are in being close the the current location of the heads. In the worst case, requests can be starved (be delayed arbitrarily long).

The Elevator Algorithm

The disk head progresses in a single direction (from the center of the disk to the edge, or vice versa) serving the closest request in that direction. When it runs out of requests in the direction it is currently moving, it switches to the opposite direction. This algorithm usually gives more equitable service to all requests, but in the worst case, it can still lead to starvation. While it is satisfying requests on one cylinder, other requests for the same cylinder could arrive. If enough requests for the same cylinder keep coming, the heads would stay at that cylinder forever, starving all other requests. This problem is easily avoided by limiting how long the heads will stay at any one cylinder. One simple scheme is only to serve the requests for the cylinder that are already there when the heads gets there. New requests for that cylinder that arrive while existing requests are being served will have to wait for the next pass.

One-way Elevator Algorithm

The simple (two-way) elevator algorithm gives poorer service to requests near the center and edges of the disk than to requests in between. Suppose it takes time T for a pass (from the center to the edge or vice versa). A request at either end of a pass (near the hub or the edge of the disk) may have to wait up to time 2T for the heads to travel to the other end and back, and on average the delay will be T. A request near the “middle” (half way between the hub and the edge) will get twice as good service: The worse-case delay is T and the average is T/2. If this bias is a problem, it can be solved by making the elevator run in one direction only (say from hub to edge). When it finishes the request closest to the edge, it seeks all the way back to the first request (the one closes to the hub) and starts another pass from hub to edge. In general, this approach will increase the total amount of seek time because of the long seek from the edge back to the hub, but on a heavily loaded disk, that seek will be so infrequent as not to make much difference.