Brad Walker writes:
>But, doesn't it seem that 1983 is a little out-dated in terms of
>technology? There is current technology that can re-order the execution
>of command so as to optimize actuator head seeks.

I'm sorry, you seem to be missing the point.  That was exactly what
the controller did and what was causing the performance problems.

>You might have a big disk
>farm with slow storage and lots of ram. The files migrate between the
>ram and slow storage depending on use. There is a company in
>Massachusetts that does this. Tagged-commands would be perfect for
>this.

Yup, in this case tagged commands could be a good idea.  However, you
would also want to queue a large number of commands, which the current
drivers can't handle so you would need a specially hacked driver for
this special case.  That's fine with me.  See Chris' suggestion that
tagged command queueing be under the control of the machine
independent SCSI layer.

>And disksort() can break down when one has things where the disk drive
>geometry is changes depending on where the head is positioned. For
>example, disksort() has an idea about a virtual drive geometry.

Actually, no.  disksort() has no idea about the drive geometry.  It
sorts the requests in increasing cylinder order and sorts within a
cylinder in increasing block order.  This works for ZBR drives too.
Since the driver tells disksort what cylinder a block lies in it could
even report the correct cylinder for ZBR drives, if it could figure
that out.

What doesn't work very well with ZBR drives is the FFS file allocation
policy.
-- 
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.