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.