Messages in this thread | | | Date | Mon, 16 Nov 1998 11:15:03 -0800 (PST) | From | Jeremy Fitzhardinge <> | Subject | Re: elevator algorithm bug in ll_rw_blk.c |
| |
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/
| |