On Sat, Jul 13, 2002 at 04:30:26PM +0100, David Laight wrote:
> On Sat, Jul 13, 2002 at 03:19:26PM +0200, Juergen Hannken-Illjes wrote:
> > The current device driver buffer queue management is not
> > very flexible. It assumes all requests are sorted on entry
> > and consumed from the head of a list.
> > 
> > This makes it impossible to use i/o scheduling strategies
> > that sort on consumption or maintain the queue in arrays or
> > multiple lists.
> 
> I tries to work out what this code did a few weeks ago.
> Got confused by the 'synchronisation' markers - I think I've
> heard since that they aren't used.
> 
> It might be worth allowing for:
> 
> - Writes to be scheduled that must happed after a previous one.
>   Eg updating file system metadata in a guaranteed order.

This is a job for the (up to now unused) B_ORDERED flag. Guarantee
that all write requests are complete before this one gets processed.
This code (the 'synchronisation' markers) is already present.
I assume it to be sufficient if these markers are only valid for
write-requests.

> - Reclaiming structures from the write queue (can this be done now?)
>   While still maintaining the ordering relation above.

I can't see a reason why a request should be taken out of the queue.
Some drivers need to drain on disconnect, but this is just

	while (bp = BUFQ_GET()) biodone()

> - allowing code to be called on completion of a write.

This looks like a job for biodone().

> These would allow the standard filesystem code to optimise
> operations while still ensuring filesystem integrity during
> operations like 'rm -rf'.
> 
> 	David
> 
> -- 
> David Laight: david@l8s.co.uk

-- 
Juergen Hannken-Illjes - hannken@eis.cs.tu-bs.de - TU Braunschweig (Germany)