Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1686463 - Issuing filelocks over NFSv4 against a GLUSTER FSAL leaks fds on the bricks and memory on nfs-ganesha
Summary: Issuing filelocks over NFSv4 against a GLUSTER FSAL leaks fds on the bricks a...
Status: CLOSED DUPLICATE of bug 1686331
Alias: None
Product: Red Hat Gluster Storage
Classification: Red Hat
Component: nfs-ganesha
Version: rhgs-3.4
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
: ---
Assignee: Kaleb KEITHLEY
QA Contact: Manisha Saini
Depends On: 1686331
TreeView+ depends on / blocked
Reported: 2019-03-07 13:59 UTC by Ron van der Wees
Modified: 2019-03-11 09:42 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2019-03-11 09:42:42 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Priority Status Summary Last Updated
Red Hat Bugzilla 1686331 None ASSIGNED [GSS] high memory usage of NFS-Ganesha process and huge number of open file descriptors from glusterd 2019-03-25 04:47:08 UTC

Description Ron van der Wees 2019-03-07 13:59:06 UTC
Description of problem:
When a file is opened, and a lock acquired, find_fd is called by glusterfs_lock_op2 to fetch the status of the fd. It in turn calls fsal_find_fd in the FSAL commonlib, and passes the open_for_locks boolean along as it got it.

Back in commit 365d7cb the following lines were changed to not always set open_for_locks to true, but have it rely on whether a state exists and if it is either a STATE_TYPE_NLM_LOCK or STATE_TYPE_9P_FID.

 status = find_fd(&my_fd, obj_hdl, bypass, state, openflags, 
 		 &has_lock, &closefd, 
 		 (state && 
 		  ((state->state_type == STATE_TYPE_NLM_LOCK) || 
(state->state_type == STATE_TYPE_9P_FID)))); 

A problem arises when using NFSv4 because this does not in fact use NLM locks. The result is that nfs-ganesha treats the lock as coming an FSAL that doesn't "bother with opening a separate file for the lock state". Although locking seems to work, this leaks a bit of memory on the ganesha.nfsd process and the glusterfsd ends up never closing the separate file. 

See also:

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