Description of problem: If the user tries to acquire a lock in the same data range for which a lock is already exists, then the second lock should fail. Version-Release number of selected component (if applicable): nfs-ganesha-gluster-2.4.1-3.el7rhgs.x86_64 glusterfs-ganesha-3.8.4-10.el7rhgs.x86_64 nfs-ganesha-2.4.1-3.el7rhgs.x86_64 How reproducible: Always Steps to Reproduce: 1. Create a file of few KB in the nfs-ganesha mount point. 2. From one client, acquire a lock for the file in specific data range. 3. From second client, try to acquire a lock for the same file in the same data range. Actual results: It allows to acquire both the locks. Expected results: It should not let other locks in the same data range to acquire while a lock is already held on the file. Additional info:
There is an issue with processing conflicting locks in FSAL_GLUSTER layer. Fix posted upstream for review - https://review.gerrithub.io/#/c/308343 This doesn't seem to be an issue at least from the code. I see similar bug in V2.3 code-path as well
> This doesn't seem to be an issue at least from the code. I see similar bug > in V2.3 code-path as well Sorry I meant this doesn't seem to be regression from earlier nfs-ganesha releases.
Tested by mounting volume with 2 different Virtual Ips on 2 clinets and tried to acquire lock in same data range from both clients. As expected he second lock is not acquired. Verified the fix in build, nfs-ganesha-2.4.1-6.el7rhgs.x86_64 nfs-ganesha-gluster-2.4.1-6.el7rhgs.x86_64 glusterfs-ganesha-3.8.4-12.el7rhgs.x86_64
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHEA-2017-0493.html