A couple of fixes?

A couple of fixes?

Posted Jul 7, 2006 14:59 UTC (Fri) by Max.Hyre (subscriber, #1054)
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 cares?)
• 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.

---

(Log in to post comments)