+++ 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) --- 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) --- 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) ------ commit 45ebcf7009f549f022c36b4d537eeac62ecfd020 Author: Pranith Kumar K <pkarampu> 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> Reviewed-on: https://review.gluster.org/17524 Smoke: Gluster Build System <jenkins.org> NetBSD-regression: NetBSD Build System <jenkins.org> CentOS-regression: Gluster Build System <jenkins.org> Reviewed-by: Ravishankar N <ravishankar>
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
Downstream patch: https://code.engineering.redhat.com/gerrit/109473
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
(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
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