Bug 763723 (GLUSTER-1991) - distribute directory self-heal does not copy user extended attributes
Summary: distribute directory self-heal does not copy user extended attributes
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: GLUSTER-1991
Product: GlusterFS
Classification: Community
Component: distribute
Version: 3.1.0
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: ---
Assignee: shishir gowda
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-10-20 23:31 UTC by Vikas Gorur
Modified: 2013-12-09 01:21 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed:
Regression: ---
Mount Type: ---
Documentation: DA
CRM:
Verified Versions:


Attachments (Terms of Use)

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.


Note You need to log in before you can comment on or make changes to this bug.