Re: elevator algorithm bug in ll_rw_blk.c

Jeremy Fitzhardinge (jsgf@sirius.com)
Mon, 16 Nov 1998 11:15:03 -0800 (PST)


On 16-Nov-98 Feuer wrote:
> Does anyone else think it might be time for a hard-disk/controller
> which did _not_ do any of this funky optimization?_ That way, people
> with smart OS's (like Linux) can have disk drivers optimized both for
> disk geometry and usage, instead of trying to work their way around
> black boxes of hardware optimization._ Possibly another option would be
> a disk/controller which could be switched (DIP switches, etc.) between
> hardware optimized for DOS, and unoptimized for Linux.

That's pretty much impossible these days, and getting harder. The reason
that devices present logical or synthesized geometries in their interfaces
is that their real geometries are very hard to characterise in a simple
way as drive technology improves. The old cylinder/head/sector idea
died when drives starting putting different numbers of sectors per track
depending on the cylinder. Even knowing the precise physical geometry
of the disk layout doesn't help unless you know the dynamic properties
of the drive too (spindle RPM, head switch time, seek time over various
distances, head settle time, number of arms, etc). And of course,
if your "drive" is really a RAID array it becomes even more moot.

There's just no way to communicate what a drive really looks like, so
the best you can do is establish some common conventions: "I'll present
25GB of linearly addressed blocks, and promise that if you write to them
in an increasing order it will be quick". Some control over the drives
policies might be quite useful in this regard.

J

-
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/