Bug 1291985 - store afr pending xattrs as a volume option
Summary: store afr pending xattrs as a volume option
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: GlusterFS
Classification: Community
Component: replicate
Version: 3.7.6
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Ravishankar N
QA Contact:
URL:
Whiteboard:
Depends On: 1285152
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-12-16 06:49 UTC by Ravishankar N
Modified: 2016-04-19 07:51 UTC (History)
1 user (show)

Fixed In Version: glusterfs-3.7.7
Clone Of: 1285152
Environment:
Last Closed: 2016-02-19 04:57:21 UTC
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Embargoed:


Attachments (Terms of Use)

Description Ravishankar N 2015-12-16 06:49:42 UTC
+++ This bug was initially created as a clone of Bug #1285152 +++

Description of problem:

    Problem:
    When AFR xlator initialises, it uses the name of the client xlators
    below it for storing the pending changelogs (xattrs). This can be
    problem when some other xlator is loaded in between AFR and the client.
    Though that is a trivial 'traverse-graph-till-the-client-and-use-the-name'
    fix in AFR's init(), there are other issues like when there's no client
    xlator at all when, say, AFR is moved to the server side.

    Fix:
    The client xlator names are currenly unique and stored as
    brickinfo->brick_ids. So persist these ids as comma separated values in
    AFR's volume_options and use them as xattr values during init().

--- Additional comment from Ravishankar N on 2015-11-24 23:46:01 EST ---

http://review.gluster.org/#/c/12738/

--- Additional comment from Vijay Bellur on 2015-11-25 04:38:04 EST ---

REVIEW: http://review.gluster.org/12738 (glusterd/afr: store afr pending xattrs as a volume option) posted (#2) for review on master by Ravishankar N (ravishankar)

--- Additional comment from Vijay Bellur on 2015-11-27 07:10:19 EST ---

REVIEW: http://review.gluster.org/12738 (glusterd/afr: store afr pending xattrs as a volume option) posted (#3) for review on master by Ravishankar N (ravishankar)

--- Additional comment from Vijay Bellur on 2015-11-27 10:18:59 EST ---

REVIEW: http://review.gluster.org/12738 (glusterd/afr: store afr pending xattrs as a volume option) posted (#4) for review on master by Ravishankar N (ravishankar)

--- Additional comment from Vijay Bellur on 2015-12-07 07:26:12 EST ---

REVIEW: http://review.gluster.org/12738 (glusterd/afr: store afr pending xattrs as a volume option) posted (#5) for review on master by Ravishankar N (ravishankar)

--- Additional comment from Vijay Bellur on 2015-12-08 03:48:23 EST ---

REVIEW: http://review.gluster.org/12738 (glusterd/afr: store afr pending xattrs as a volume option) posted (#6) for review on master by Ravishankar N (ravishankar)

--- Additional comment from Vijay Bellur on 2015-12-08 16:47:06 EST ---

REVIEW: http://review.gluster.org/12738 (glusterd/afr: store afr pending xattrs as a volume option) posted (#7) for review on master by Vijay Bellur (vbellur)

--- Additional comment from Vijay Bellur on 2015-12-15 12:59:29 EST ---

REVIEW: http://review.gluster.org/12738 (glusterd/afr: store afr pending xattrs as a volume option) posted (#8) for review on master by Ravishankar N (ravishankar)

--- Additional comment from Vijay Bellur on 2015-12-16 01:17:18 EST ---

COMMIT: http://review.gluster.org/12738 committed in master by Atin Mukherjee (amukherj) 
------
commit 6e635284a4411b816d4d860a28262c9e6dc4bd6a
Author: Ravishankar N <ravishankar>
Date:   Wed Nov 25 09:49:19 2015 +0530

    glusterd/afr: store afr pending xattrs as a volume option
    
    Problem:
    When AFR xlator initialises, it uses the name of the client xlators
    below it for storing the pending changelogs (xattrs). This can be
    problem when some other xlator is loaded in between AFR and the client.
    Though that is a trivial 'traverse-graph-till-the-client-and-use-the-name'
    fix in AFR's init(), there are other issues like when there's no client
    xlator at all when, say, AFR is moved to the server side.
    
    Fix:
    The client xlator names are currenly unique and stored as
    brickinfo->brick_ids. So persist these ids as comma separated values in
    AFR's volume_options and use them as xattr values during init().
    
    Change-Id: Ie761ffeb3373a4c4d85ad05c84a768c4188aa90d
    BUG: 1285152
    Signed-off-by: Ravishankar N <ravishankar>
    Reviewed-on: http://review.gluster.org/12738
    Tested-by: NetBSD Build System <jenkins.org>
    Tested-by: Gluster Build System <jenkins.com>
    Reviewed-by: Atin Mukherjee <amukherj>

Comment 1 Vijay Bellur 2015-12-16 06:50:42 UTC
REVIEW: http://review.gluster.org/12977 (glusterd/afr: store afr pending xattrs as a volume option) posted (#1) for review on release-3.7 by Ravishankar N (ravishankar)

Comment 2 Vijay Bellur 2015-12-17 06:02:59 UTC
COMMIT: http://review.gluster.org/12977 committed in release-3.7 by Atin Mukherjee (amukherj) 
------
commit 486b07dfc33782d27e3458659cdd6090f496ad35
Author: Ravishankar N <ravishankar>
Date:   Wed Nov 25 09:49:19 2015 +0530

    glusterd/afr: store afr pending xattrs as a volume option
    
    Backport of http://review.gluster.org/#/c/12738/
    
    Problem:
    When AFR xlator initialises, it uses the name of the client xlators
    below it for storing the pending changelogs (xattrs). This can be
    problem when some other xlator is loaded in between AFR and the client.
    Though that is a trivial 'traverse-graph-till-the-client-and-use-the-name'
    fix in AFR's init(), there are other issues like when there's no client
    xlator at all when, say, AFR is moved to the server side.
    
    Fix:
    The client xlator names are currenly unique and stored as
    brickinfo->brick_ids. So persist these ids as comma separated values in
    AFR's volume_options and use them as xattr values during init().
    
    Change-Id: Ie761ffeb3373a4c4d85ad05c84a768c4188aa90d
    BUG: 1291985
    Signed-off-by: Ravishankar N <ravishankar>
    Reviewed-on: http://review.gluster.org/12977
    Tested-by: NetBSD Build System <jenkins.org>
    Reviewed-by: Pranith Kumar Karampuri <pkarampu>
    Tested-by: Gluster Build System <jenkins.com>

Comment 3 Ravishankar N 2016-02-19 04:57:21 UTC
v3.7.7 contains a fix

Comment 4 Kaushal 2016-04-19 07:51:02 UTC
This bug is getting closed because a release has been made available that should address the reported issue. In case the problem is still not fixed with glusterfs-3.7.7, please open a new bug report.

glusterfs-3.7.7 has been announced on the Gluster mailinglists [1], packages for several distributions should become available in the near future. Keep an eye on the Gluster Users mailinglist [2] and the update infrastructure for your distribution.

[1] https://www.gluster.org/pipermail/gluster-users/2016-February/025292.html
[2] http://thread.gmane.org/gmane.comp.file-systems.gluster.user


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