>Thor Lancelot Simon <tls@rek.tjls.com>
> On Tue, Apr 10, 2001 at 02:14:05AM -0700, Simon J. Gerraty wrote:
> > In case that's not clear, imagine that each time the system goes to accept 
> > a write - it looks at the length out the write out queue, and if its less
> > than some minimal length (or its length last time we looked) we accept
> > the write, otherwise we block it.

Hmm actually <= last length, otherwise you'd never grow the queue to
its optimal size :-)

> Exactly.  This kind of implementation has some other nifty properties.  For
> example, if you've got tasks that produce "optional" I/O, such as coalescing
> files (or, in an extent-based filesystem, extents) or aggressively cleaning
[snip details]
> However, to get this right you need either two queues or some notion of
> "cancellable" requests.  Otherwise "optional" I/O can seriously delay real
> I/O.  SGI has a white paper on using two queues for this kind of thing but
> I think explicitly marking some requests as cancellable is a better idea.

My initial reaction to that was - "but won't that mean these optional
I/Os will never happen".  If that is what you wanted, cool.  But if
these should be considered more like "low priority" I/O's that should
eventually make it to disk, then I'd expect 2 queues would be simpler
to implement and get right.  Within the low priority queue they may
still want to be cancellable - eg. when a new request that is a
superset of an existing one comes along.

I must admit that 2 queues strikes me as simpler - you can almost use
the same heuristic for accepting new requests for each.  For the main
queue you only consider its length, for the optional queue you
consider its length plus the main queue.  But I've no real basis for
that position other than my own virtual reality :-)

--sjg