jgh@gec-mi-at.co.uk (Jeremy Harris) (10/28/86)
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@gec-mi-at.co.uk ...!mcvax!ukc!hrc63!miduet!jgh