Bug 1463104 - lk fop succeeds even when lock is not acquired on at least quorum number of bricks
lk fop succeeds even when lock is not acquired on at least quorum number of b...
Status: CLOSED ERRATA
Product: Red Hat Gluster Storage
Classification: Red Hat
Component: replicate (Show other bugs)
3.3
Unspecified Unspecified
unspecified Severity unspecified
: ---
: RHGS 3.3.0
Assigned To: Ravishankar N
nchilaka
:
Depends On: 1461792
Blocks: 1417151 1462661
  Show dependency treegraph
 
Reported: 2017-06-20 03:04 EDT by Pranith Kumar K
Modified: 2017-09-21 00:59 EDT (History)
4 users (show)

See Also:
Fixed In Version: glusterfs-3.8.4-29
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: 1461792
Environment:
Last Closed: 2017-09-21 00:59:42 EDT
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)

  None (edit)
Description Pranith Kumar K 2017-06-20 03:04:19 EDT
+++ This bug was initially created as a clone of Bug #1461792 +++

Description of problem:
When testing gluster-block we are seeing that even when just one of the bricks is up lk fop is succeeding. This can lead to problems. Fix AFR behavior where lk fop considers quorum count to decide if lk fop succeeds or not.

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

--- Additional comment from Worker Ant on 2017-06-15 07:20:05 EDT ---

REVIEW: https://review.gluster.org/17524 (cluster/afr: Implement quorum for lk fop) posted (#3) for review on master by Pranith Kumar Karampuri (pkarampu@redhat.com)

--- Additional comment from Worker Ant on 2017-06-18 12:36:29 EDT ---

REVIEW: https://review.gluster.org/17524 (cluster/afr: Implement quorum for lk fop) posted (#4) for review on master by Pranith Kumar Karampuri (pkarampu@redhat.com)

--- Additional comment from Worker Ant on 2017-06-19 01:17:32 EDT ---

COMMIT: https://review.gluster.org/17524 committed in master by Pranith Kumar Karampuri (pkarampu@redhat.com) 
------
commit 45ebcf7009f549f022c36b4d537eeac62ecfd020
Author: Pranith Kumar K <pkarampu@redhat.com>
Date:   Mon Jun 12 22:06:18 2017 +0530

    cluster/afr: Implement quorum for lk fop
    
    Problem:
    At the moment when we have replica 3 or arbiter setup, even when
    lk succeeds on just one brick we give success to application which
    is wrong
    
    Fix:
    Consider quorum-number of successes as success when quorum is enabled.
    
    BUG: 1461792
    Change-Id: I5789e6eb5defb68f8a0eb9cd594d316f5cdebaea
    Signed-off-by: Pranith Kumar K <pkarampu@redhat.com>
    Reviewed-on: https://review.gluster.org/17524
    Smoke: Gluster Build System <jenkins@build.gluster.org>
    NetBSD-regression: NetBSD Build System <jenkins@build.gluster.org>
    CentOS-regression: Gluster Build System <jenkins@build.gluster.org>
    Reviewed-by: Ravishankar N <ravishankar@redhat.com>
Comment 2 Pranith Kumar K 2017-06-20 03:05:59 EDT
https://review.gluster.org/17524

Steps to verify:
Bring two of the bricks in replica-3 and execute gluster-block info <volname>/<blkname> it should fail
Comment 3 Pranith Kumar K 2017-06-20 03:17:58 EDT
Downstream patch: https://code.engineering.redhat.com/gerrit/109473
Comment 7 nchilaka 2017-06-27 09:44:34 EDT
qa test:
=====
when client side quorum is lost i notice that i am unable to do an flock(firstly the file handle reserve itself doesnt work)
hence marking as pass
however I noticed that(need to be related to this fix), that if a fhandle is opened on a file and client quorum is lost, I see there is data loss
raised bz#1465462 - stale file handles leads to data loss on loss of client side quorum
Comment 8 nchilaka 2017-06-27 10:01:02 EDT
(In reply to nchilaka from comment #7)
> qa test:
> =====
> when client side quorum is lost i notice that i am unable to do an
> flock(firstly the file handle reserve itself doesnt work)
> hence marking as pass
> however I noticed that(need to be related to this fix), that if a fhandle is
> opened on a file and client quorum is lost, I see there is data loss
> raised bz#1465462 - stale file handles leads to data loss on loss of client
> side quorum

as the BZ#1465462 is not a bug, moving this bz to verified

test version:
3.8.4.31
Comment 10 errata-xmlrpc 2017-09-21 00:59:42 EDT
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.

https://access.redhat.com/errata/RHBA-2017:2774

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