Bug 1151308 - data loss when rebalance + renames are in progress and bricks from replica pairs goes down and comes back
Summary: data loss when rebalance + renames are in progress and bricks from replica pa...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: GlusterFS
Classification: Community
Component: replicate
Version: 3.4.5
Hardware: x86_64
OS: Linux
urgent
urgent
Target Milestone: ---
Assignee: bugs@gluster.org
QA Contact:
URL:
Whiteboard:
Depends On: 1140643 1141539 1144450
Blocks: glusterfs-3.4.6 1141733 1142020 glusterfs-3.4.7
TreeView+ depends on / blocked
 
Reported: 2014-10-10 05:21 UTC by Raghavendra G
Modified: 2015-12-01 16:45 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of: 1141539
Environment:
Last Closed: 2015-04-13 06:58:08 UTC
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Embargoed:


Attachments (Terms of Use)

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>


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