Latest Developer Headlines · Open Source Targets Microsoft Exchange [BusinessWeek] · McDonald's Offers WiFi [Seattle Post Intelligencer ] · Hackers Contest Makes a Mess of Internet [Sify] · Hacking Contest Threatens Web Sites [Information Week] · Microsoft Launches Digital ID Software [CNet] submit | more ...

What's New on ACM Queue · A Conversation with Jim Gray · How Much Storage is Enough? · You Don't Know Jack about Disks · Programming Without a Net · Web Services: Promises and Compromises

Magnetic disk drives have been at the heart of computer systems since the early 1960s. They brought not only a significant advantage in processing performance, but also a new level of complexity for programmers. The three-dimensional geometry of a disk drive replaced the simple, linear, address spacetape-based programming model.

Whatever happened to cylinders and tracks?

Traditionally, the programmer's working model of disk storage has consisted of a set of uniform cylinders, each with a set of uniform tracks, which in turn hold a fixed number of 512-byte sectors, each with a unique address. The cylinder is made up of concentric circles (or tracks) on each disk platter in a multiplatter drive. Each track is divided up like pie slices into sectors. Because any location in this three-dimensional storage space could be uniquely identified by the cylinder number, head (surface) number, and sector number, this formed the basis for the original programming model for disk drives: cylinder-head-sector access.

This raises the question: If that is how data is stored on a drive, why don't we still use that as the programming model? The answer is not an easy one but has its roots in the fact that this geometric model endured until the advent of the intelligent inter-faces, SCSI and ATA. [The IBM mainframe world used a slightly different model, allowing tracks to be written with records (blocks) of user-defined length. An individual track could have sectors of different sizes. As one who programmed count key data (CKD) storage, I can attest that it offers the application wonderful flexibility, but the drive design challenges have relegated it to history. Also, a purist might point out that standards etiquette calls for SCSI to use blocks and ATA to use sectors, but I will use these terms interchangeably.]

Disk-interface protocols implement the programming model for disk drives. The earlier drive interfaces did little more than expose signals to let the host directly manipulate the drive mechanism and initiate a transfer of data at a target location. This put the task of dealing with all the low-level idiosyncrasies peculiar to drives on the programmer charged with developing the firmware or software support.

The introduction of ATA and SCSI fundamentally changed this. Table 1 describes the migration of intelligence from host to drive in the evolution of the more important interfaces. With these intelligent interface protocols, the task of programming the use of disk drives became much easier. Disk-drive designers also gained a freedom of action needed to design higher-capacity and higher-performance drives. I will look at just how drive designers used this freedom of action in their designs, but it is important first to understand the fundamental goal behind drive design: increasing areal density.

Table 1
Movement of Intelligence from Host to Drive

Comment on this Article in the ACM Queue Forums
	Next Page (2/7) The Basics: TPI and BPI