David Brownlee writes:

> On all but very low memory machines I tend to set NVNODE to
> 131072 or 262144. It does consume quite a bit of memory, but
> it does help dealing with large directory structures (pkgsrc,
> large websites, rsyncing).
 .. and also mentions changes in -current 

Thank you .. I think I was looking for a kernel complaint about 
this being a resource issue rather than silently locking up.  (A
complaint would be sort of chicken+egg anyway).  I shouldn't have under
estimated kern.maxvnodes either and I'm hoping by following your
guidance and metzger's recommendations that this will no longer be an issue.  

I'm wondering if this could also be related to responding/not-responding
issues with the NFS server?  Though its behaviour was never like the 
clients, it again could just be resources and nothing to do with 
network throughput.

Right now the NFS clients are hanging around between 65000 - 70000
vnodes since the change about 2 hours ago (now 256k).  They all have 1GB
of RAM each .. the NFS server just reported 112596 vnodes which is almost
4 times higher than its ever used (because kern.maxvnodes was limited to
32k previous).  

As far as current, I'm glad to hear the good news.  I have a couple of
machines I usually use for testing current, but because of a problem
I've experienced with the fxp driver, I've had to revert back to the
release.  Thank you again for the advice.