Bug 1335433

Summary:	Self heal shows different information for the same volume from each node
Product:	[Community] GlusterFS	Reporter:	Pranith Kumar K <pkarampu>
Component:	sharding	Assignee:	Pranith Kumar K <pkarampu>
Status:	CLOSED CURRENTRELEASE	QA Contact:	bugs <bugs>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	3.8.0	CC:	atalur, bugs, kdhananj, pcuzner, pkarampu, ravishankar, sabose
Target Milestone:	---	Keywords:	Triaged
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:	glusterfs-3.8rc2	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:	1334566	Environment:
Last Closed:	2016-06-16 14:06:29 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:	1334566
Bug Blocks:	1335429

Description Pranith Kumar K 2016-05-12 08:42:20 UTC

+++ This bug was initially created as a clone of Bug #1334566 +++

Description of problem:
I noticed that nagios was showing heal required in the BAGL test environment, but when I checked on node gprfc085, self heal was 0.

However, I ran the following 

for node in gprfc085 gprfc086 gprfc087; do pssh -P -t 60 -H $node 'date; gluster vol heal engine info ; sleep 1'; done

and could see that on node 85, self heal was 0 but the other two nodes show shards listed.

Trying to understand why...I did note that for some reason cluster.data-self-heal/entry-self-heal and meta

To date, this issue is ONLY against the 'engine' volume, which is sharded volume and has the hosted_engine vm running on node '86


Version-Release number of selected component (if applicable):


How reproducible:
Each time.

Steps to Reproduce:
1. Run vol heal commands on each node at around the same time
2. 
3.

Actual results:
1 node shows the volume is clean, the other 2 invariably report shards in the heal list.

Expected results:
I would expect all nodes to have the same view of heal state

Additional info:
output attached
glusterfs-3.7.9-3 build

--- Additional comment from Sahina Bose on 2016-05-11 10:57:22 EDT ---

Krutika, can you take a look?

Comment 1 Vijay Bellur 2016-05-12 08:46:26 UTC

REVIEW: http://review.gluster.org/14303 (cluster/afr: Handle non-zero source in heal-info decision) posted (#1) for review on release-3.8 by Pranith Kumar Karampuri (pkarampu)

Comment 2 Vijay Bellur 2016-05-14 14:12:41 UTC

COMMIT: http://review.gluster.org/14303 committed in release-3.8 by Niels de Vos (ndevos) 
------
commit 91dcbfb58ac06b84940d3de9049514465a3acd6b
Author: Pranith Kumar K <pkarampu>
Date:   Thu May 12 13:55:44 2016 +0530

    cluster/afr: Handle non-zero source in heal-info decision
    
            Backport of http://review.gluster.org/14302
    
    Problem:
    Spurious entries are reported in heal info when the mount is on second/third
    brick of the replica pair because local-child is given preference in selecting
    source. The code is supposed to suggest the file needs heal if the (source < 0)
    (failure code path), but instead it is written as if any non-zero value
    is considered failure.
    
    Fix:
    Treat +ve source as success case
    
    BUG: 1335433
    Change-Id: Iede983b6560622964e91306405587da3f1de5748
    Signed-off-by: Pranith Kumar K <pkarampu>
    Reviewed-on: http://review.gluster.org/14303
    Reviewed-by: Krutika Dhananjay <kdhananj>
    Smoke: Gluster Build System <jenkins.com>
    NetBSD-regression: NetBSD Build System <jenkins.org>
    CentOS-regression: Gluster Build System <jenkins.com>
    Reviewed-by: Ravishankar N <ravishankar>
    Reviewed-by: Anuradha Talur <atalur>
    Reviewed-by: Niels de Vos <ndevos>

Comment 3 Niels de Vos 2016-06-16 14:06:29 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.8.0, please open a new bug report.

glusterfs-3.8.0 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] http://blog.gluster.org/2016/06/glusterfs-3-8-released/
[2] http://thread.gmane.org/gmane.comp.file-systems.gluster.user