Bug 1194546
| Summary: | Write behind returns success for a write irrespective of a conflicting lock held by another application | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Community] GlusterFS | Reporter: | Anoop C S <anoopcs> | ||||
| Component: | write-behind | Assignee: | Sanju <srakonde> | ||||
| Status: | CLOSED UPSTREAM | QA Contact: | |||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | mainline | CC: | bugs, jahernan, ndevos, pkarampu, rtalur, sarumuga, sheggodu, skoduri | ||||
| Target Milestone: | --- | Keywords: | StudentProject, Triaged | ||||
| Target Release: | --- | ||||||
| Hardware: | x86_64 | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2020-03-17 03:30:50 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
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 |
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.