The cylinder/head/sector numbers have been lies for years. With a SCSI
disk you could read the true geometries, including sectors per track in
each of the various zones, together with the defect map and know exactly
where each block lies on the disk...but the angular position of the disc
is a whopping 11 ms variable (5400 RPM), and you can't optimize for it
in the OS without guessing at it, then hoping you aren't interrupted
too badly before acting on that guess.
Leave the nitty gritty to the disk (for SCSI, or for IDE writes); just
get the requests in rough order without starving anyone and things
should go quickly and smoothly. Worst case, you plan to request a track's
blocks in reverse order, but the dumb IDE disk has nothing better to do but
to read the track into its buffer when it finishes seeking, so within a rev
the data for a whole batch of pessimal requests is in the buffer.
> i think it was rsx-11 which used to format the disk to take into account
> retational delays
I've seen DOS floppy formatting programs that do that. Meanwhile, since
hard disk makers have been bragging about sustained transfer rate for the
past several years, I can guarantee they've skewed the tracks properly to
optimize sequential reads across track boundaries...and not even a SCSI
drive will tell you the value of this skew, AFAIK...
> of course the other side of the coin is that all this sorting increases the
> potential for problems when metadata on the disk becomes inconsistent. i know
> disks are pretty reliable these days, but the os has been know to crash now and
> then :-)
There's going to be power interruptions at inconvenient times no matter what
you do.
Keith
-- "The avalanche has already started; |Linux: http://www.linuxhq.com |"Zooty, it is too late for the pebbles to |KDE: http://www.kde.org | zoot vote." Kosh, "Believers", Babylon 5 |Keith: kwrohrer@enteract.com | zoot!" www.midwinter.com/lurk/lurker.html |http://www.enteract.com/~kwrohrer | --Rebo- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/