Re: elevator algorithm bug in ll_rw_blk.c

Billy Harvey (Billy.Harvey@thrillseeker.net)
Mon, 16 Nov 1998 09:51:01 -0500


> > > You could apply a two way elevator well if you knew about the physical
> > > characteristics of the drive. Unfortunately there is no way to find that out
> > > for most modern drives.
> >
> > Hmmm, why not?
> >
> > root@rhino /root> hdparm -I /dev/hda
...
> > With that kind of knowledge, what kind of improvements could be made to
> > the driver?
>
> Because this is not true at all. Your driver doesn't have 16 heads, nor
> 63 sectors per tracks. Modern IDE disks have usually 2, 4 or 6 heads,
> and variable number of sectors per track and the values they report are
> there only to work with older software that can't do LBA.

Thanks to several who gave me an education about true disk geometry vs
reported. I do have a follow-on question. The hdparm command for
example can determine the drive model. Given that, and data sheets,
shouldn't a hd driver be able to choose from a database of tuning
parameters to optimize drive access? The fallback could always be the
simpler, straight-forward approach taken now. This would require either
manufacturer's data put into the table, or probably even better, timing
based on probing of the drive model. Do drives vary much any more
between copies of the same model, so would an inidividual drive need to
be optimized, or just a model?

Would this be worth the effort? Would we get, say double the read speed
in general-purpose access, or perhaps in specialized efforts, such as
large database access?

Billy

-- 
Billy.Harvey@thrillseeker.net

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