Hide Forgot
Steps to reproduce for QA: - Create a distribute volume with two bricks and mount at /mnt # mkdir /mnt/dir.{1..64} # mkdir /mnt/dir.{1..64}/foo # setfattr -n trusted.test -v 42 /mnt/dir.{1..64}/foo - add-brick with 2 more bricks # ls -lR /mnt # setfattr -x trusted.test /mnt/dir.{1..64}/foo This will remove the xattr from only one of the bricks. This can be verified at the backend. # getfattr -d -m. /mnt/dir.{1..64}/foo Some of these results will be garbage instead of "42". After the patch is applied, verify from backend that the extended attributes are deleted from ALL backends.
Submitted: http://patches.gluster.com/patch/6178/
DHT now sends setxattr() to all the subvolumes. This is necessary to preserve semantics for extended attributes on directories. Without this, when a volume expansion takes place, setxattr() can go to a different subvolume than previously, leading to missing attributes, etc. The same problem still affects removexattr(). Currently DHT sends it only to the hashed subvolume. So when a volume expansion happens, it is possible that although removexattr() is sent to the hashed subvolume, the xattr actually exists on some other subvolume. To the user it will appear as though removexattr() sometimes behaves like a no-op. The fix is to send removexattr() to all subvolumes of DHT.
PATCH: http://patches.gluster.com/patch/6178 in master (cluster/dht: Send removexattr() to all subvolumes.)
tested with 3.1.2 ,extended attrib. not removed from all backend. verified with commit-id "26cedae57d5b7cb8d50ed077ce29c92e30d6e260" -extended attrib.removed from all backends.