Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1151308

Summary: data loss when rebalance + renames are in progress and bricks from replica pairs goes down and comes back
Product: [Community] GlusterFS Reporter: Raghavendra G <rgowdapp>
Component: replicateAssignee: bugs <bugs>
Status: CLOSED CURRENTRELEASE QA Contact:
Severity: urgent Docs Contact:
Priority: urgent    
Version: 3.4.5CC: bugs, kkeithle, nsathyan, pkarampu, shmohan, ssamanta, vbellur
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 1141539 Environment:
Last Closed: 2015-04-13 06:58:08 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:
Bug Depends On: 1140643, 1141539, 1144450    
Bug Blocks: 1125245, 1141733, 1142020, 1154714    

Comment 1 Anand Avati 2014-10-13 02:08:18 UTC
REVIEW: http://review.gluster.org/8923 (cluster/afr: Handle EAGAIN properly in inodelk) posted (#1) for review on release-3.4 by Pranith Kumar Karampuri (pkarampu)

Comment 2 Anand Avati 2014-10-30 14:18:36 UTC
COMMIT: http://review.gluster.org/8923 committed in release-3.4 by Kaleb KEITHLEY (kkeithle) 
------
commit dc8a3490e437d25ac2ee94a74778cd16c778514d
Author: Pranith Kumar K <pkarampu>
Date:   Mon Sep 15 14:22:44 2014 +0530

    cluster/afr: Handle EAGAIN properly in inodelk
    
            Backport of http://review.gluster.org/8739
    
    Problem:
    When one of the brick is taken down and brough back up in a replica pair, locks
    on that brick will be allowed. Afr returns inodelk success even when one of the
    bricks already has the lock taken.
    
    Fix:
    If any brick returns EAGAIN return failure to parent xlator.
    
    Note: This change only works for non-blocking inodelks. This patch addresses
    dht-synchronization which uses non-blocking locks for rename. Blocking lock is
    issued by only one of the rebalance processes. So for now there is no
    possibility of deadlock.
    
    BUG: 1151308
    Change-Id: I72f15d8789442c29b5c7be2d5dabf7bae6bfa845
    Signed-off-by: Pranith Kumar K <pkarampu>
    Reviewed-on: http://review.gluster.org/8923
    Tested-by: Gluster Build System <jenkins.com>
    Reviewed-by: Niels de Vos <ndevos>
    Reviewed-by: Kaleb KEITHLEY <kkeithle>