The fact that the replacement sectors are transparent to the programmer of a hard disk driver causes interesting challenges when optimising hard disk performance. To see why, observe the following:

A hard disk usually consists of several magnetic platters, which can be written and read on both sides. Each platter contains many concentric rings of data, all in differerent sizes, which are called tracks. The collection of all equally sized tracks that lie above one another on different disk surfaces is called a cylinder. Finally, all the disks are 'divided' much like a pizza or a pie by imaginary lines. One slice of the pie is called a sector.

This terminology enables us to find specific pieces of data on the disk.The data is written in such a way that each sector of each track on each platter contains exactly the same amount of data. This means, of course, that the data near the center of the platter is written in a much smaller space than the data at the edge, since the arc from the track that lies within one sector is much smaller there. Together, the concepts of track, sector and platter enable us to identify unique pieces of data of some atomic size, since all arcs contain the same amount of data. This amount is called a block. Blocks are the smallest unit that can be written to, or read from, disk.

When a specific block needs to be accessed, there are three phases the disk needs to go through. Each of these phases is NOT transparent to the programmer of the disk driver! The driver programmer must explicitly direct the head to a track and a sector, facing her or him with some interesting design challenges, as we will see below.

First, the read head must be directed to the right track. This is called a seek. This is by far the slowest and most time consuming activity. Second, the head needs to wait until the proper part of the disk, containing the desired sector, spins under the disk head. The time that passes in this phase is called the rotational delay. It is on average half of the full rotation time of the disk, but much faster than the seek time. Finally, the data can be read to an internal buffer, and then transported to main memory so the processor can access it. The disk will issue an interrupt when it is ready. The read time is exactly the time it takes to spin one sector under the head.

A disk driver usually receives several requests for data blocks at a time. Which should it service first? Well, First Come First Serve seems the most fair, but it is very unwise. Remember that a seek takes the most time? It makes more sense to pick those blocks that have the shortest seek time (are closest to the current position), since that will greatly reduce the overall response time for all users. This is called Shortest Seek First. Unfortunately, this is not very practical. It is likely that the read head will spend its days in the middle of the disk, while blocks on the edges rarely get a chance to be serviced (think about it!). Practically, it is most feasible to just have the head sweep from one edge to another and then back again, picking up blocks along the way and turning at the most extreme request point. This is called the Elevator Algorithm (for fairly obvious reasons). The moral of this story is: disk efficiency is very dependent on the disk seeking algorithm used by the programmer of your driver.

The problem with modern disk controllers and clever optimisation of seek times is this: what if a disk block is damaged and the IDE controller secretly uses some spare block on a spare track? Well, since the actual physical location of the block can no longer be seen by the driver programmer, this wreaks havoc with our clever seek optimisation algorithms! Is there something that can be done about this you ask? No!

Footnote: modern disks sometimes have more sectors in the outer tracks, to make better use of the available space. This makes the problem even worse, because the IDE controllers hide this information from the driver programmer. To the programmer, the disk will appear as a normal disk with conventional sectors, tracks and cylinders. The driver programmer has no way of knowing the actual physical location of blocks on the disk.