yes, an I/O scheduler which allowed for prioritization hints from the
layers above it would be most excellent!

while we're adding things to the wish-list, the ability to request
cancellation of in-flight I/Os would be good as well.  this would
allow us to reduce the effect of things like async flushes of
files that are deleted before the I/O requests actually make it
down to the hardware.

-Chuck


On Thu, Jan 25, 2001 at 03:46:34PM -0500, Bill Sommerfeld wrote:
> > To flesh this out a bit further, I'd think we'd want to flag this kind
> > of I/O request such that it could be deferred if "real" I/O came in
> > while it was still in the queue, to avoid buzzing the heads all over
> > the disk and slowing down new I/O because of the backlog of "optional"
> > stuff; Irix uses two queues for a similar purpose to this, with one
> > having priority over the other when commands are actually issued.
> 
> On a related note, I've long wondered whether it would make sense to
> project the BSD adaptive scheduler priority scheme (favoring
> interactive processes over "batch") into disk queue ordering..
> 
> The raidframe parity rebuild could just be a "nice 20" process under a
> scheme like that.
> 
> 					- Bill