[Bugs] [Bug 1471613] New: metadata heal not happening despite having an active sink
bugzilla at redhat.com
bugzilla at redhat.com
Mon Jul 17 04:59:07 UTC 2017
https://bugzilla.redhat.com/show_bug.cgi?id=1471613
Bug ID: 1471613
Summary: metadata heal not happening despite having an active
sink
Product: GlusterFS
Version: 3.8
Component: replicate
Keywords: Triaged
Assignee: bugs at gluster.org
Reporter: ravishankar at redhat.com
CC: bugs at gluster.org
Depends On: 1468279
Blocks: 1471611, 1471612
+++ This bug was initially created as a clone of Bug #1468279 +++
Description of problem:
In a replica 3 volume, afr pending xattrs for metadata on 3 bricks are as
follows:
Brick1- C1=1
Brick2- C0=1
Brick3- C0=0, C1=0
With these xattrs, __afr_selfheal_metadata_prepare() returned zero sinks and
heal was not happening.
How to recreate:
1. Kill B1, do metadata modification operation on a file (say setfattr).
2. Kill B2, bring up B1, let metadata heal happen from B3 to B1.
3. Again do metadata modification operation on a file.
4. Kill B1, bring up B2, let metadata heal happen from B3 to B2.
5. Bring up B1 again. All bricks are up now.
6. Heal info never comes to zero.
--- Additional comment from Worker Ant on 2017-07-06 10:33:59 EDT ---
REVIEW: https://review.gluster.org/17717 (afr: mark non sources as sinks in
metadata heal) posted (#1) for review on master by Ravishankar N
(ravishankar at redhat.com)
--- Additional comment from Worker Ant on 2017-07-06 13:00:59 EDT ---
REVIEW: https://review.gluster.org/17717 (afr: mark non sources as sinks in
metadata heal) posted (#2) for review on master by Ravishankar N
(ravishankar at redhat.com)
--- Additional comment from Worker Ant on 2017-07-07 01:58:16 EDT ---
REVIEW: https://review.gluster.org/17717 (afr: mark non sources as sinks in
metadata heal) posted (#3) for review on master by Ravishankar N
(ravishankar at redhat.com)
--- Additional comment from Worker Ant on 2017-07-13 03:19:17 EDT ---
REVIEW: https://review.gluster.org/17717 (afr: mark non sources as sinks in
metadata heal) posted (#4) for review on master by Ravishankar N
(ravishankar at redhat.com)
--- Additional comment from Worker Ant on 2017-07-13 06:45:57 EDT ---
REVIEW: https://review.gluster.org/17717 (afr: mark non sources as sinks in
metadata heal) posted (#5) for review on master by Ravishankar N
(ravishankar at redhat.com)
--- Additional comment from Worker Ant on 2017-07-13 07:53:39 EDT ---
REVIEW: https://review.gluster.org/17717 (afr: mark non sources as sinks in
metadata heal) posted (#6) for review on master by Ravishankar N
(ravishankar at redhat.com)
--- Additional comment from Worker Ant on 2017-07-13 13:23:02 EDT ---
COMMIT: https://review.gluster.org/17717 committed in master by Pranith Kumar
Karampuri (pkarampu at redhat.com)
------
commit 77c1ed5fd299914e91ff034d78ef6e3600b9151c
Author: Ravishankar N <ravishankar at redhat.com>
Date: Thu Jul 6 19:49:47 2017 +0530
afr: mark non sources as sinks in metadata heal
Problem:
In a 3 way replica, when the source brick does not have pending xattrs
for the sinks, but the 2 sinks blame each other, metadata heal was not
happpening because we were not setting all non-sources as sinks.
Fix: Mark all non-sources as sinks, like it is done in data and entry
heal.
Change-Id: I534978940f5087302e307fcc810a48ffe898ce08
BUG: 1468279
Signed-off-by: Ravishankar N <ravishankar at redhat.com>
Reviewed-on: https://review.gluster.org/17717
Smoke: Gluster Build System <jenkins at build.gluster.org>
Reviewed-by: Pranith Kumar Karampuri <pkarampu at redhat.com>
CentOS-regression: Gluster Build System <jenkins at build.gluster.org>
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1468279
[Bug 1468279] metadata heal not happening despite having an active sink
https://bugzilla.redhat.com/show_bug.cgi?id=1471611
[Bug 1471611] metadata heal not happening despite having an active sink
https://bugzilla.redhat.com/show_bug.cgi?id=1471612
[Bug 1471612] metadata heal not happening despite having an active sink
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
More information about the Bugs
mailing list