A couple of fixes?
Posted Jul 7, 2006 14:59 UTC (Fri) by Max.Hyre
Parent article: The 2006 Linux Filesystems Workshop (Part II)
It seems to me that the disk controller hardware could fix
two of the problems. These have to be done at the
controller level, for speed and because the OS has no idea
what the disk's real geometry is.
First, how about dual heads to allow read-after-write, as
tapes have had since the dawn of time? That'll
catch the high-flying writes, and
blocks with oxide problems.
Second, for over-powered seeks, I suspect you need to get
below the filesystem to the real format, the one
the OS never sees. IIRC, waaay back
when I was paying attention to disk details, the track had
an ID actually written in it. You could check that to
make sure you were in the right place.
Of course, this has a couple of drawbacks:
- it would require the track number in each
block, so you don't have to wait for the start of the
track to come around before you know where you are,
thus losing some capacity (but who
- it would still add a delay of one full rotation
every Nth write, where N = # blocks/track, because
that's how often the first block you get is the one you
want to write. Do they already have block numbers
(instead of some physical position sensor, which
sounds pretty squirrely to me)? If so,
you've already got this problem, so it isn't a factor.
It might be worth it, depending on the
frequency of overshoot (or undershoot?) errors, and how
often the write load overpowers the cache's ability to
hide the delays.
to post comments)