# Disk Geometry

Hard disk drives are called by that name because they are not floppy (as in floppy disk drives). They are organized as a concentric stack of disks or "platters":

Each platter has two surfaces (although in practice the outer surfaces on the top and bottom of the stack are often unused because of physical space considerations), and each has its own read/write head (which reads and writes data magnetically on the surface). The data is stored on concentric circles on the surfaces known as tracks:
Corresponding tracks on all surfaces on a drive, when taken together, make up a cylinder:
The time it takes to move the read/write head to the desired cylinder is called the seek time.
blocks can be addressed by specifying the cylinder, head and sector numbers of the block ("CHS"). The time it takes for the desired sector to rotate into position under the read/write head is called the latency; timing marks are recorded on the disc to facilitate sector location. The sum of the seek time, the latency and the read time is called the access time.
It is interesting to note that most IDE (Integrated Drive Electronics), SCSI (Small Computer System Interface) and SATA (Serial ATA, or "Advanced Technology Attachment") disk drives pretend to have a far different geometry than they actually have physically. For instance, a typical hard drive might tell the operating system that it has 16,384 cylinders, 80 heads and 63 sectors per track; since 80 heads implies at least 40 platters, each with 2 surfaces, we see immediately that this cannot represent the physical contents of a hard drive which is just 3/4 of an inch thick! In fact, most hard drives have only one or two platters, and the geometry they pretend to have is there for the software's sake, as we shall see below.
IDE, SCSI and SATA disk drives can address blocks logically, treating the disk drive as a series of blocks numbered from 0 to n. It might seem, then, that organizing the drive in this geometrical fashion is unnecessary. There are still two reasons why disk geometry is relevant:
1. as we noted previously, antiquated programming on BIOS chips prevents many computers from loading an operating system from a cylinder number larger than 1023;
2. on multitasking computers, outstanding read and write data requests for a hard drive are scheduled by track number to minimize head movement.
If the requests were serviced on a first come first served basis (FCFS, or first in first out - FIFO), the head would in general have to move randomly back and forth over the surfaces. This can make seek times unnecessarily large, since it takes extra time for the head to change direction. The seek scheduling algorithm SCAN attempts to make the head move smoothly across the surface, reading and writing data as the appropriate tracks appear under the heads. It is also possible to schedule based on serving the shortest seek time first (SEEK).

The following applet allows you to simulate these algorithms under a variety of load conditions:

Start the simulation using the Start button. After it has finished, you may change any parameters (or not) and start a new simulation using the Start button again. The display indicates in red when and where a request is made and in black the path followed by the disk head. The message window displays a summary of each simulation. The message window can be cleared using the Clear button.

You need a Java-capable browser to be able to work with this applet.

Consider our disk drive which has 16,384 cylinders, 80 heads and 63 sectors per track. For historical reasons, a sector has 512 bytes (which suggests that early operating systems allocated just 9 bits for the sector part of a disk address; 512 = 29). What is the capacity of such a disk? We can use units to calculate how much storage is available. Our basic equation is
? bytes = 1 disk
The conversion factors appropriate to this hard disk are

• 16,384 cylinders / disk
• 63 sectors / track
• 512 bytes / sector

Notice that the traditional nomenclature is "heads per cylinder" and "sectors per track". Since there is only one head able to access any given track (on any given surface), we have an implicit conversion factor available to us:

Note too that two of these conversion factors correspond to powers of 2:
16,384 = 214
63 = 26 - 1
This suggests that these values are intimately related to the number of bits which are used to store the cylinder and sector numbers, respectively.

The computation of the hard drive capacity then proceeds as follows:

? bytes = 1 disk * (16,384 cylinders / disk) * (80 heads / cylinder) * (1 track / head) *
(63 sectors / track) * (512 bytes / sector)

= 42,278,584,320 bytes

This is a large and rather inconvenient number. We adopt the following "metric" prefixes when discussing storage space:

• 1 Kilobyte (KB) = 210 bytes = 1,024 bytes
• 1 Megabyte (MB) = 220 bytes = 1,048,576 bytes = 1,024 KB
• 1 Gigabyte (GB) = 230 bytes = 1,073,741,824 bytes = 1,048,576 KB = 1,024 MB
• 1 Terabyte (TB) = 240 bytes = 1,099,511,627,776 bytes = 1,073,741,824 KB = 1,048,576 MB = 1,024 GB
• 1 Petabyte (PB) = 250 bytes = 1,125,899,906,842,624 bytes = 1,099,511,627,776 KB = 1,073,741,824 MB = 1,048,576 GB = 1,024 TB
• 1 Exabyte (EB) = 260 bytes = 1,152,921,504,606,846,976 bytes = 1,125,899,906,842,624 KB = 1,099,511,627,776 MB = 1,073,741,824 GB = 1,048,576 TB = 1,024 PB

Using these definitions, our result would be expressed in GB as :

42,278,584,320 bytes / (1,073,741,824 bytes / GB) = 39.375 GB
These definitions represent common usage among memory manufacturers and operating systems programmers, in contradiction to the strict powers of ten used by scientists throughout the world, as well as by hard drive manufacturers:

• K = 103 = 1,000
• M = 106 = 1,000,000
• G = 109 = 1,000,000,000
• T = 1012 = 1,000,000,000,000
• P = 1015 = 1,000,000,000,000,000
• E = 1018 = 1,000,000,000,000,000,000

It is important to realize that the manufacturers of most disk drives quote capacities which are considerably larger than the actual usable amount of space available on the drive. This is because some space is unavoidably lost when the "raw" tracks are separated into sectors: sectors have gaps between them which are needed for timing reasons, and they also have addresses and checksums for error checking. So our 39.375 GB would be described by a manufacturer as something noticably larger than the 42.279 GB which strict powers of ten would imply.