Bug 1356976

Summary:	seeing dataheal pending bits bump up when source databrick is down and arbiter does metadata and entry heal
Product:	[Community] GlusterFS	Reporter:	Nag Pavan Chilakam <nchilaka>
Component:	arbiter	Assignee:	Ravishankar N <ravishankar>
Status:	CLOSED NOTABUG	QA Contact:
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	3.7.9	CC:	bugs, rkavunga
Target Milestone:	---	Keywords:	Triaged
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2016-07-20 12:38:06 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:

Description Nag Pavan Chilakam 2016-07-15 12:16:27 UTC

Description of problem:
==========================
I see that the dataheal bits in truster.afr xattr are getting bumped up when arbiter brick heals  a destination data brick for metadata and entry heal while source brick is down

Version-Release number of selected component (if applicable):
glusterfs 3.9dev built on Jul 11 2016 10:04:54

How reproducible:
always


Steps to Reproduce:
================
1.create a 1x(2+1) replicate arbiter vol
2.now mount the vol by fuse
3.create a directory say dir1
4. Now bring down the first data brick(db1) 
5. create a file sat f1 under dir1 with some contents 
6. note down the getfattr details from both db2 and ab1 
for eg below is the info:
===>from db2:
[root@dhcp43-153 ~]# getfattr -d -m . -e hex /bricks/brick1/arbit/db1_Down/datafile
getfattr: Removing leading '/' from absolute path names
# file: bricks/brick1/arbit/db1_Down/datafile
security.selinux=0x73797374656d5f753a6f626a6563745f723a756e6c6162656c65645f743a733000
trusted.afr.arbit-client-0=0x000000020000000200000000
trusted.afr.dirty=0x000000000000000000000000
trusted.bit-rot.version=0x02000000000000005788cb300009088d
trusted.gfid=0x091d29ddf4e149da83531686e59818de

===>from ab1:
[root@dhcp43-157 ~]#  getfattr -d -m . -e hex /bricks/brick2/arbit/db1_Down/datafile
getfattr: Removing leading '/' from absolute path names
# file: bricks/brick2/arbit/db1_Down/datafile
security.selinux=0x73797374656d5f753a6f626a6563745f723a756e6c6162656c65645f743a733000
trusted.afr.arbit-client-0=0x000000020000000200000000
trusted.afr.dirty=0x000000000000000000000000
trusted.bit-rot.version=0x02000000000000005788cb3000085f14
trusted.gfid=0x091d29ddf4e149da83531686e59818de


7.Now bring down the other data brick too ie db2
7. bring up the db1 which was down while keeping db2 down
8. check heal info and trigger a manual heal
9. once the entry and metadata heal is over check the xattr info on ab1 for the file. It can be seen that the data bit is bumped up

[root@dhcp43-157 ~]#  getfattr -d -m . -e hex /bricks/brick2/arbit/db1_Down/datafile
getfattr: Removing leading '/' from absolute path names
# file: bricks/brick2/arbit/db1_Down/datafile
security.selinux=0x73797374656d5f753a6f626a6563745f723a756e6c6162656c65645f743a733000
trusted.afr.arbit-client-0=0x000000030000000000000000
trusted.afr.dirty=0x000000000000000000000000
trusted.bit-rot.version=0x02000000000000005788cb3000085f14
trusted.gfid=0x091d29ddf4e149da83531686e59818de



This shouldn't be happening

Comment 1 Ravishankar N 2016-07-20 12:38:06 UTC

This is expected behaviour. When an entry self heal results in new entry (file) creation on the sink bricks, the data and metadata changelogs of that file are incremented on the source brick(s) to indicate that they need to be healed too. This is mostly uselful in replace brick scenarios. 

The reason why you only see dataheal pending bits (and not metadata bit) is because the metadata bit, though incremented, was cleared after the heal completed. The databit remained because arbiter cannot be used for data heal.