Rafal Boni wrote:
> 
> In message <3C4F3303.BBE8A25F@l8s.co.uk>, you write:
> 
> -> If I do:
> ->
> -> dsl@snowdrop:-ksh$ cd /usr/bsd-current
> -> dsl@snowdrop:-ksh$ time find . | wc
> ->   109552  109552 4153470
> ->   166.93s real     1.81s user     1.23s system
> -> dsl@snowdrop:-ksh$ time find . |wc
> ->   109552  109552 4153470
> ->   165.35s real     1.75s user     1.27s system
> ->
> -> Repeating the find takes about the same length of time, the disk
> -> 'rattles' throughout.  Memory use (reported by 'top') stays basically
> -> constant 'Memory: 33M Act, 308K Wired, 187M Free, 1025M Swp free'.
> 
> I bet you run out of vnodes, the vnodes for stuff you've already gotten get
> recycled and you have to go back to disk to fetch the necessary data.  I'm
> willing to bet money on the first half, but I'm unsure why you'd need to go
> to disk again anyway -- is this some fallout from metadata not being in UBC?

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.

Seems to me that file system 'metadata' - which seems to include
directory contents - should use the UBC.  Clearly you need to grab some
kernel address space - troublesome on ultra? sparc if the page is
already mapped into a user process - having found the correct block(s)
lurking in physical memory.

Maybe a sight modification to the LRU rule - so that blocks that have
been referenced a lot are likely to be kept for longer?  I have an idea
- but don't want to trash my system when I get it wrong - I don't have a
test machine :-)
> 
> (I assume you're running -current)

Of course - synced yesterday morning...  Not pulled in the new ipf stuff
today since it takes about 90 minutes.

	David