> 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