Bug 714027 - LockStateID
Summary: LockStateID
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: nfs-utils
Version: 14
Hardware: All
OS: Linux
unspecified
urgent
Target Milestone: ---
Assignee: Steve Dickson
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-06-17 07:16 UTC by Bjorge Solli
Modified: 2011-10-04 17:47 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-10-04 17:47:19 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Bjorge Solli 2011-06-17 07:16:00 UTC
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
------------------------
Hi,

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

.....

IMPLEMENTATION

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
should use RELEASE_LOCKOWNER.
---

Comment 1 J. Bruce Fields 2011-06-17 19:58:13 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.