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

One quirk of the old mainframes was very long disk queues -- hundreds
or even thousands of requests.  Ordering made sense here.

I believe that the requests were ordered in _inverse_ CPU priority;
that is, a high CPU priority would mean a low disk queueing priority.
This is what you want for parity builds and lfs cleaners.  It is also
consistent with earliest-completion scheduling:  you give preference
to clients using the least amount of a resource.