Red Hat Bugzilla – Full Text Bug Listing
|Summary:||nlm:ulock does not happen after the server is back|
|Product:||[Community] GlusterFS||Reporter:||Saurabh <saujain>|
|Component:||nfs||Assignee:||Vivek Agarwal <vagarwal>|
|Status:||CLOSED CURRENTRELEASE||QA Contact:||Saurabh <saujain>|
|Version:||pre-release||CC:||gluster-bugs, mzywusko, sankarshan, sdharane, vbellur|
|Fixed In Version:||glusterfs-3.4.0||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2013-07-24 13:30:42 EDT||Type:||Bug|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Saurabh 2012-05-17 04:34:47 EDT
Description of problem: this issue happens when the script is sent for sleep and nfs server is restarted after the script holding the lock comes of sleep Version-Release number of selected component (if applicable): 3.3.0qa40 How reproducible: always Steps to Reproduce: 1. create a dist-rep(2x2) volume 2. nfs mount the volume 3. now try to put lock on a file and put the script on sleep for some time. 4. meanwhile kill the gnfs process. 5. when the script is out the sleep , start the gnfs again. Actual results: the unlock of the volume fails, with these messages. returns:- nlm_get_uniq() returned NULL and unable to unlock_fd_resume Expected results: this unlock should happen Additional info: the unlock happens when nfs is killed and restarted during the sleep period itself.
Comment 1 Krishna Srinivas 2012-05-18 06:53:45 EDT
during nfs server restart, if nfs server is started after unlock() call, the nfs client does not send a reclaim lock request when it gets SM_NOTIFY before sending the unlock request. And hence the server is unable to find any info related to the unlock call and returns error. nfs server should return success for unlock call if it is not able to find any locks held whenever there is an unlock request. (this is how kernel nfs server behaves)
Comment 2 Krishna Srinivas 2012-07-30 02:43:56 EDT
Commit 04f6cd78fab5a2fa8a02da3be27b080a15aec203 fixes the issue.