+++ This bug was initially created as a clone of Bug #808400 +++ Description of problem: On a graph change, along with the fd migration the locks acquired must also be migrated. How reproducible: Always Steps to Reproduce: 1. Acquire locks on a file 2. Perform volume set command that will change the graph 3. Then, try acquiring lock on the same range again from a different program. Actual results: The new lock is granted. Expected results: The new lock must not be granted. Additional info: --- Additional comment from aavati on 2012-05-15 19:52:45 EDT --- CHANGE: http://review.gluster.com/3227 (mount/fuse: Use state->lk_lock to print lock information on EAGAIN.) merged in master by Anand Avati (avati)
*** Bug 852424 has been marked as a duplicate of this bug. ***
Tested on glusterfs-3.4.0qa4-1. Attached is the test program to test the case. Steps to verify: Create a gluster volume distribute/replicate/stripe ... * Lock a file in one terminal. * Do a few graph changes (This should migrate the locks across the graphs). * Try to lock the file from another terminal (This should fail/block). * Unlock the file in terminal 1 and the lock should the acquired in terminal 2.
Created attachment 661369 [details] Program to test lock migration.
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. http://rhn.redhat.com/errata/RHBA-2013-1262.html