nfsd server cache flooded, try to increase nfsrc_floodlevel

Rick Macklem rmacklem at uoguelph.ca
Fri Jul 22 22:16:51 UTC 2011


Clinton Adams wrote:
[stuff snipped for brevity]
> 
> Running four clients now and the LockOwners are steadily climbing,
> nfsstat consistently reported it as 0 prior to users logging into the
> nfsv4 test systems - my testing via ssh didn't show anything like
> this. Attached tcpdump file is from when I first noticed the jump in
> LockOwners from 0 to ~600. I tried wireshark on this and didn't see
> any releaselockowner operations.
> 
[stuff snipped for brevity]
> OpenOwner Opens LockOwner Locks Delegs
> 6 242 2481 22 0
> Server Cache Stats:
> Inprog Idem Non-idem Misses CacheSize TCPPeak
> 0 0 2 2518251 2502 4772
> 
I've written a small test program:
  http://people.freebsd.org/~rmacklem/childlock.c (also attached)

where a parent process opens a file and then forks children that do
lock ops and then exit. (I'm guessing that this is what some process
in your clients are doing, that result in the LockOwner count growing.)

When I run this program on Fedora15, it generates ReleaseLockOwner Ops
and the LockOwner count doesn't increase as it runs.

You can run this program by giving it an argument that can be any file
on the nfsv4 mount for which you have read/write access, then watch
the server via "nfsstat -e -s" to see if the LockOwner count increases.

If the LockOwner count does increase, then it appears that a newer Linux
kernel will avoid the problem.

If you are interested in what the packet trace looks like when running the
program on Fedora15, it's at:
  http://people.freebsd.org/~rmacklem/childlock.pcap

rick
ps: The FreeBSD NFSv4 client doesn't currently generate the ReleaseLockOwner
    Ops for this case either. I need to come up with a patch that does that.



More information about the freebsd-fs mailing list