Bug 1194546 - Write behind returns success for a write irrespective of a conflicting lock held by another application
Summary: Write behind returns success for a write irrespective of a conflicting lock h...
Status: ASSIGNED
Alias: None
Product: GlusterFS
Classification: Community
Component: write-behind (Show other bugs)
(Show other bugs)
Version: mainline
Hardware: x86_64 Linux
unspecified
medium
Target Milestone: ---
Assignee: Raghavendra Talur
QA Contact:
URL:
Whiteboard:
Keywords: Triaged
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-02-20 06:48 UTC by Anoop C S
Modified: 2016-07-05 09:51 UTC (History)
6 users (show)

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 06:48 UTC, Anoop C S
no flags Details

Description Anoop C S 2015-02-20 06:48:42 UTC
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 11:59:03 UTC
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 12:27:12 UTC
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 12:39:27 UTC
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-30 04:17:13 UTC
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 09:51:14 UTC
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.