nfsd server cache flooded, try to increase nfsrc_floodlevel

[Clinton Adams]

On Sat, Jul 23, 2011 at 12:16 AM, Rick Macklem <rmacklem at uoguelph.ca> wrote:
> 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.

Yes, a client running a newer kernel (2.6.38) does generate the
release_lockowner ops.

Thanks for all the help!

>
> 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.
>
>