>Brad Walker writes:
>
>>> From: bad@flatlin.ka.sub.org (Christoph Badura)
>>> Except the buffer cache and the disksort routine are supposed to do
>>> that already.
>
>>But, they don't optimize for head actuator position.
>
>Huh?  That's what the disksort routine is supposed to take care of.

disksort routine??  i dont know quite what the best way is, but it seems
to me that this may also hurt performance on modern drives with variable
sectors/track.  i know my drive certainly is not as fast as i think it
should be, and makes very odd sounding seek patterns often.  they sound
much less than optimal...

-chris

>
>Except, of course, with devices that remap bad sectors to far away
>tracks behind the initiators back.
>
>>> It could well be that the target gets it wrong and the performance
>>> gets worse.  There is a CSRG paper about such an experience with a
>>> non-SCSI controller that did it's own ordering.
>
>>Quote your source.. 
>
>Kridle, R., and McKusick, M., "Performance Effects of Disk Subsystem
>Choices for VAX Systems Running 4.2BSD UNIX", CSRG, Dept of EECS, UCB
>technical report #8, 1983
>
>>And it is worth mentioning that this is paper is
>>most likely quite a few years old. Before current technology.
>
>I don't think someone has invented a way for disk controller firmware
>to divine the optimal execution order of requests in the last 13
>years.
>
>The performance problems were with the disk controller re-ordering the
>requests.  They went away when they disabled that "feature."
>
>-- 
>Christoph Badura	bad@flatlin.ka.sub.org
>
>You don't need to quote my .signature.  Everyone has seen it by now.
>Besides, it doesn't add anything to the current thread.