Bug 1238398

Summary:	Unable to examine file in metadata split-brain after setting `replica.split-brain-choice' attribute to a particular replica
Product:	[Red Hat Storage] Red Hat Gluster Storage	Reporter:	Shruti Sampat <ssampat>
Component:	replicate	Assignee:	Anuradha <atalur>
Status:	CLOSED ERRATA	QA Contact:	Shruti Sampat <ssampat>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	rhgs-3.1	CC:	annair, asriram, asrivast, atalur, divya, nsathyan, pkarampu, rhs-bugs, smohan, storage-qa-internal
Target Milestone:	---	Keywords:	ZStream
Target Release:	RHGS 3.1.1
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	glusterfs-3.7.1-13	Doc Type:	Bug Fix
Doc Text:	Previously, the split-brain-choice was not being considered when a file is only in the metadata split-brain. As a consequence, incorrect file metadata (with fops like ls, stat) was getting displayed for files in split-brain through the mount even after you set replica.split-brain-choice. With this fix, the correct metadata is displayed.	Story Points:	---
Clone Of:
Clones:	1240244 (view as bug list)		Environment:
Last Closed:	2015-10-05 07:17:52 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:
Bug Blocks:	1216951, 1240244, 1251815, 1256909

Description Shruti Sampat 2015-07-01 19:12:10 UTC

Description of problem:
------------------------

After choosing a particular replica as `replica.split-brain-choice', `ls' or `stat' on a file/directory in metadata split-brain does not report correct results always.

For e.g., consider the case of mismatching permissions on both replicas. After choosing one of the replicas (say, client-0) as the choice to examine the file, `ls -l' gives the appropriate permissions. On choosing the other replica, (say client-1), `ls -l' does not show the permissions from client-1, instead shows the same permissions as those on client-0.

This behavior, however, is not seen in case of mismatching xattrs on both replicas.

Version-Release number of selected component (if applicable):
-------------------------------------------------------------
glusterfs-3.7.1-6.el7rhgs.x86_64

How reproducible:
-----------------
Always

Steps to Reproduce:
--------------------
1. Create a 1x2 volume, start it and fuse mount it.
2. Create a file or directory on the mount point.
3. Kill one replica and change the permissions of the file from the mount point.
4. Bring back the killed brick and kill the other replica.
5. Change permissions of the file from the mount point again.
6. Bring back killed brick and examine the permissions of the file using `ls -l' command after choosing a replica as the replica.split-brain-choice on the mount point -

# setfattr -n replica.split-brain-choice -v "new-client-1" testfile

Actual results:
----------------

Incorrect permissions are shown after selecting a replica as replica.split-brain-choice.

Expected results:
------------------
Correct permissions need to be shown on selecting a particular replica as replica.split-brain-choice.

Additional info:

Comment 2 Anuradha 2015-07-06 10:47:38 UTC

Patch posted upstream for review:

http://review.gluster.org/11551

Comment 5 monti lawrence 2015-07-23 14:52:14 UTC

Doc text is edited. Please sign off to be included in Known Issues.

Comment 9 Shruti Sampat 2015-09-07 17:41:50 UTC

Verified as fixed in glusterfs-3.7.1-14.el7rhgs.x86_64. Tested for a file in metadata split-brain in a distribute-replicate setup and found to be working. In case of a directory in metadata split-brain in a distribute-replicate setup, the `replica.split-brain-status' of the directory reports that it is not in split-brain (BZ #1260779). In case of a pure replica, verified that it is possible to examine the directory in metadata split-brain correctly after choosing appropriate choice as `replica.split-brain-choice'.

Comment 10 Divya 2015-09-23 07:02:16 UTC

Please review and sign-off the edited doc text.

Comment 11 Anuradha 2015-09-23 07:20:09 UTC

Looks good to me.

Comment 13 errata-xmlrpc 2015-10-05 07:17:52 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHSA-2015-1845.html