Created attachment 993827 [details] Contains the required patch and test program Description of problem: When mandatory-locking is enabled for a particular volume and a write is performed on a particular file, write-behind immediately returns success irrespective of a conflicting lock held by another application. Version-Release number of selected component (if applicable): mainline How reproducible: Always Steps to Reproduce: Apply the attached patch, install and perform the following steps. 1. Create and start a basic distributed volume with mandatory-locks enabled. Note:- volume set option for enabling mandatory-locks is as follows gluster volume set <VOLNAME> mandatory-locks on 2. Fuse mount the volume at two different mount-points. 3. Create an empty file from mount-point. 4. Run app1.c [see attachment] from one mount-point, with path to the empty file as command-line argument till it acquires a shared lock on it. 5. Run app2.c [see attachment] with path to the empty file as command-line argument. Actual results: Write returned success. Expected results: Write should wait[blocking mode] or should fail[non-blocking mode] Additional info: Compile the attached programs and run as per the above mentioned steps.
REVIEW: http://review.gluster.org/10350 (performance/write-behind: lk and write calls should be ordered) posted (#1) for review on master by Raghavendra Talur (rtalur)
REVIEW: http://review.gluster.org/10350 (performance/write-behind: lk and write calls should be ordered) posted (#2) for review on master by Raghavendra Talur (rtalur)
REVIEW: http://review.gluster.org/10350 (performance/write-behind: lk and write calls should be ordered) posted (#3) for review on master by Raghavendra Talur (rtalur)
Just an observation. With [1], write can be successful. Only fsync or close make sure that writes are synced to disk. So, If necessary please make relevant changes to your tests. [1] review.gluster.org/12594
REVIEW: http://review.gluster.org/10350 (performance/write-behind: lk and write calls should be ordered) posted (#4) for review on master by Raghavendra Talur (rtalur)
None of the above patches were merged. What's the status?
The patch posted(http://review.gluster.org/10350) for review handles the case where: If both process A and B are on the same Gluster client machine, then it ensures write-behind orders write and lock requests from both the processes in the right order. On review, Raghavendra G commented with the following example and review: A write w1 is done and is cached in write-behind. A mandatory lock is held by same thread which conflicts with w1 (Is that even a valid case? If not, probably we don't need this patch at all). This mandatory lock goes through write-behind and locks xlator grants this lock. Now write-behind flushes w1 and posix-locks fails w1 as a conflicting mandatory lock is held. But now that I think of it, it seems like an invalid (exotic at its best) use-case. Anoop/Raghavendra G, From mandatory locking and write-behind perspective, is it still an exotic case? If so, we can close this bug.
(In reply to Raghavendra Talur from comment #7) > The patch posted(http://review.gluster.org/10350) for review handles the > case where: > If both process A and B are on the same Gluster client machine, then it > ensures write-behind orders write and lock requests from both the processes > in the right order. > > > On review, Raghavendra G commented with the following example and review: > A write w1 is done and is cached in write-behind. > A mandatory lock is held by same thread which conflicts with w1 (Is that > even a valid case? If not, probably we don't need this patch at all). This > mandatory lock goes through write-behind and locks xlator grants this lock. > Now write-behind flushes w1 and posix-locks fails w1 as a conflicting > mandatory lock is held. > But now that I think of it, it seems like an invalid (exotic at its best) > use-case. What I missed above is when write and lock requests happen from two different processes on same mount point (which the commit msg says). For that case, this patch is still required. > > > Anoop/Raghavendra G, > > From mandatory locking and write-behind perspective, is it still an exotic > case? If so, we can close this bug. No. I was wrong. This patch is required for multiple process scenario.
I've restored the patch, but it ran into conflict. Can you refresh?
REVIEW: https://review.gluster.org/23224 (performance/write-behind: lk and write calls should be ordered) posted (#1) for review on master by Rishubh Jain
Rishubh, any progress on this ?
Moving the bug back to assigned because the patch is abandoned.
This bug is moved to https://github.com/gluster/glusterfs/issues/1113, and will be tracked there from now on. Visit GitHub issues URL for further details