Bug 763723 (GLUSTER-1991)

Summary:	distribute directory self-heal does not copy user extended attributes
Product:	[Community] GlusterFS	Reporter:	Vikas Gorur <vikas>
Component:	distribute	Assignee:	shishir gowda <sgowda>
Status:	CLOSED CURRENTRELEASE	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	3.1.0	CC:	amarts, anush, divya, gluster-bugs, nsathyan, renee, vijay
Target Milestone:	---
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:		Type:	---
Regression:	---	Mount Type:	---
Documentation:	DA	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description Vikas Gorur 2010-10-20 23:31:48 UTC

Consider the case where there is a simple 2-node replicate cluster on which the user has stored "user.*" extended attributes on directories. Now if two new nodes (as a replicate pair) are added and the 4-node cluster configured as distribute+replicate, the user will lose access to the attributes.

This is because dht sends getxattr() only to the hashed subvolume, thus half of the calls will go to the new 2-node pair where the "user.*" attributes don't exist.

The fix is that when dht self-heals the directories it should copy any "user.*" attributes it finds.

Comment 1 Renee 2010-11-01 13:25:23 UTC

raising priority on this one.

Comment 2 Anand Avati 2010-11-03 08:25:39 UTC

PATCH: http://patches.gluster.com/patch/5630 in master (Fix DHT getxattr for directories)

Comment 3 Vikas Gorur 2010-11-03 13:21:45 UTC

This is only a partial fix. What happens if after the expansion the user updates the value of an existing attribute? This setxattr could go to the new subvolume, thus resulting in the same key existing on two different subvolumes with different values. Merging them would then result in that key being repeated in the result.

Comment 4 Vijay Bellur 2010-11-03 13:30:47 UTC

(In reply to comment #3)
> This is only a partial fix. What happens if after the expansion the user
> updates the value of an existing attribute? This setxattr could go to the new
> subvolume, thus resulting in the same key existing on two different subvolumes
> with different values. Merging them would then result in that key being
> repeated in the result.

dict_copy() merges the key without repeating in the result.

Comment 5 Vikas Gorur 2010-11-03 13:38:22 UTC

How can we be sure that the value that's left in the end is the updated value and not the old value?

Comment 6 Vikas Gorur 2010-12-01 15:29:53 UTC

This problem is solved as a side-effect of this patch:
http://patches.gluster.com/patch/5150/

The patch makes dht send setxattr to ALL subvolumes. So if an existing attribute's value is updated, all subvolumes will have the same value. Hence there is no chance of the old value being returned.

Comment 7 Amar Tumballi 2011-02-15 06:25:19 UTC

A FAQ entry saying, only with 3.1.2 releases, Distribute self-heal will copy the extendend attribute.

Comment 8 Divya 2011-03-17 06:06:30 UTC

Added the following in 3.1.3 Release Notes (Issues Resolved... section): Fixed the issue generated during self-heal of directories, or rebalance of layout
happening on distributed volumes. The extended attributes are now copied/healed
appropriately.