Bug 714027

Summary: LockStateID
Product: [Fedora] Fedora Reporter: Bjorge Solli <bjorge>
Component: nfs-utilsAssignee: Steve Dickson <steved>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: urgent Docs Contact:
Priority: unspecified    
Version: 14CC: bfields, jlayton, mcb, steved
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-10-04 13:47:19 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description Bjorge Solli 2011-06-17 03:16:00 EDT
Description of the problem:
In the RFC for NFSv4 there is a section about RELEASE_LOCKOWNER (14.2.37) which is optional.  We have 5-600 Fedora 14 clients that talk to 3 Solaris NFS-servers and the problem we experience is that the clients don't release the locks, and the servers over time accumulate locks until it reaches a max value (in Solaris this is a little over 1 million).  After the server hits the max value, a restart of the NFS service on the server is necessary to fix the problem.

We ask that Fedora implements RELEASE_LOCKOWNER in Fedora 14, and also check if this has been implemented in RHEL 5 and 6, as we also use those on our servers.

Please see below the comment from Oracle technical support and a subscript from the RFC:

Generic Note

It has been confirmed that the cause of the problem is on the client rather than the server - the client is not releasing the Lockowner - see the section from RFC 3530 below. A fix will be produced for Solaris NFS clients but this will not help in your situation as the clients which are creating the high values of LockStateID are all running Fedora 14. The proper solution is to have the fault on Fedora 14 fixed.

Cite from the RFC 3530:

14.2.37. Operation 39: RELEASE_LOCKOWNER - Release Lockowner State



The client may choose to use this operation to ease the amount of
server state that is held. Depending on behavior of applications at
the client, it may be important for the client to use this operation
since the server has certain obligations with respect to holding a
reference to a lock_owner as long as the associated file is open.
Therefore, if the client knows for certain that the lock_owner will
no longer be used under the context of the associated open_owner4, it
Comment 1 J. Bruce Fields 2011-06-17 15:58:13 EDT
Fixed for rhel6 as fix for bz 621304, fixed in upstream by d3c7b7ccc199ee564177ee914c04771d6bc00295, included in 2.6.36, so should be OK in Fedora 15.