> 
> Today's experiments have shown this is caused by exceeding the size of
> the 'buffer cache' - ie increasing the buffer cache size makes it
> possible to scan a larger directory tree without wearing the disk out.
> 

Things seem to be somewhat worse, I've been grovelling (find . -name
'*.[ch] | xargs grep) through the kernel sources.  du -s gives a size of
128Mb (including some files which won't be grepped), top reports that my
system (x86 pc) has 180Mb of 'free' memory, but the searches rattle the
disk.  If the UBC if working properly in ought to find all the pages it
wants sat in memory from the previous run.

The buffer cache (currently the default 13Mb) is large enough that 'find
. | wc' leaves all the data it wants cached,  however 'du -s .' has to
access the disk.  I can't see how the latter requires access to any more
data.

Anyone know what is really going on here?

FWIW I've found this snippet of code in brelse() (kern/vfs_bio.c):

                if (bp->b_vp) {
                        reassignbuf(bp, bp->b_vp);
                        brelvp(bp);
                }
 
I can't see the point of the reassignbuf() at all - even if it weren't
followed by a brelvp() call, which makes it particularly pointless.

	David