bflush algorithm

[Jeremy Harris]

After bflush finds a delayed-write block and asynch-writes it, it scans again
from the start of the freelist. Code to do this is in AT&T SysV.2 (Vax),
Uniplus SysV.2 (m68k) and BSD 4.2 (Vax).

I assume this is for safety in case some other process inserts a delayed-write
block on the freelist, but who will do this?
o	Not any other real process since the scheduler won't preempt the
	kernel-mode  process  doing the  bflush  unless it goes to sleep
	(which it doesn't).
o	The  disk driver  strategy  routine called by bwrite?   I see no
	reason for it to manipulate the freelist.
o	A  disk  interrupt?   The only time  iodone puts anything on the
	freelist is if the  block was  ASYNC.  Which means that it is no
	longer DELWRI.
That only leaves comms protocols which write direct to disk from kernel.  Boy
do you have a wierd system :-)

So what am I missing?  I'd hate to think that this is one of those simple but
inefficient  algorithms  left over from  when memory was expensive and  buffer
caches  were small.  When playing with a memory-rich system with  4096 buffers
I have  seen a  sync(1)  result in  830  blocks  being written  for a  cost of
2.8 MILLION  buffer headers scanned.  Looks quadratic to me.....  And the hack
to change the behaviour is all of two lines.

Most of the words above are trademarks, or otherwise owned by, somebody,
somewhere. I don't speak for any of them.
Jeremy Harris	jgh at gec-mi-at.co.uk	...!mcvax!ukc!hrc63!miduet!jgh