Bug 762484 (GLUSTER-752) - Locks on the server do not get cleaned up on fd close
Summary: Locks on the server do not get cleaned up on fd close
Keywords:
Status: CLOSED NOTABUG
Alias: GLUSTER-752
Product: GlusterFS
Classification: Community
Component: locks
Version: mainline
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Pavan Vilas Sondur
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-03-24 06:48 UTC by Pavan Vilas Sondur
Modified: 2015-12-01 16:45 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed:
Regression: RTNR
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:


Attachments (Terms of Use)

Description Pavan Vilas Sondur 2010-03-24 06:48:35 UTC
Locks do not get cleaned up in protocol/server when the application does just an fd close, without explicitly unlocking the held locks. They get cleaned up only when the client is down.

Comment 1 Pavan Vilas Sondur 2010-03-24 10:12:39 UTC
In fact, server is not leaking posix locks. protocol/server does not maintain a lock table for posix locks and passes the flush along and locks translator cleans up accordingly. Same case with release cbk.

However, inodelks and entrylks are always explicitly unlocked. Nevertheless, they are cleaned in pl_forget if any are present in the locks translator, which indicates a bug in the user of inodelks/entrylks.

Since, protocol/server adds and removes internal locks during lock and unlock requests respectively, there is not really a bug i.e. no locks remain in the lock table of protocol server.

Marking this invalid.


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