This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 1194546 - Write behind returns success for a write irrespective of a conflicting lock held by another application
Write behind returns success for a write irrespective of a conflicting lock h...
Status: ASSIGNED
Product: GlusterFS
Classification: Community
Component: write-behind (Show other bugs)
mainline
x86_64 Linux
unspecified Severity medium
: ---
: ---
Assigned To: Raghavendra Talur
: Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-02-20 01:48 EST by Anoop C S
Modified: 2016-07-05 05:51 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Contains the required patch and test program (2.61 KB, application/zip)
2015-02-20 01:48 EST, Anoop C S
no flags Details

  None (edit)
Description Anoop C S 2015-02-20 01:48:42 EST
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.
Comment 1 Anand Avati 2015-04-23 07:59:03 EDT
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@redhat.com)
Comment 2 Anand Avati 2015-04-23 08:27:12 EDT
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@redhat.com)
Comment 3 Anand Avati 2015-04-28 08:39:27 EDT
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@redhat.com)
Comment 4 Raghavendra G 2015-11-29 23:17:13 EST
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
Comment 5 Vijay Bellur 2016-07-05 05:51:14 EDT
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@redhat.com)

Note You need to log in before you can comment on or make changes to this bug.