Hide Forgot
If one of distribute's subvolumes has a directory that has user xattrs set, and another subvolume does not have them set, this bug will appear. Steps to reproduce: - Create replicated volume with 2 bricks. Mount on /mnt # mkdir -p /mnt/dir.{1..64}/foo # setfattr -n trusted.test -v 42 /mnt/dir.{1..64}/foo - Add two more bricks. # ls -lR /mnt # setfattr -x trusted.test /mnt/dir.{1..64}/foo Now the attribute has been deleted from the hashed subvolume. # getfattr -d -m. /mnt/dir.{1..64}/foo Some of these will return junk data.
This can be reproduced in an even simpler way: - Create a distribute-only volume with 2 subvolumes. - Create many directories and set xattrs on them. - Delete all xattrs on one of the backends. - getxattr() on the mountpoint now sometimes returns junk. It appears that the bug appears easily the first time getfattr is run after mount. So to reproduce, re-mount often and run getfattr.
Patch submitted: http://patches.gluster.com/patch/6207/
When testing the above patch, please run under valgrind and check for memory leaks as well.
PATCH: http://patches.gluster.com/patch/6207 in master (libglusterfs/dict: memcpy() data_t in unserialize.)
(In reply to comment #1) > This can be reproduced in an even simpler way: > > - Create a distribute-only volume with 2 subvolumes. > - Create many directories and set xattrs on them. > - Delete all xattrs on one of the backends. > - getxattr() on the mountpoint now sometimes returns junk. > > It appears that the bug appears easily the first time getfattr is run after > mount. So to reproduce, re-mount often and run getfattr. tested with 3.1.2 - sometimes junk appears in extended.attrib. # getfattr -d -m . dir.{1..64}/foo # file: dir.1/foo trusted.test=0sADDqdA== # file: dir.2/foo trusted.test=0sADDqdA== # file: dir.3/foo trusted.test="0248" # file: dir.4/foo trusted.test="0248" # file: dir.5/foo trusted.test=0sADDqdA== # file: dir.6/foo trusted.test="0248" ---------------------------------------- but with git-commit id 26cedae57d5b7cb8d50ed077ce29c92e30d6e260 - no junk appeared. # file: dir.1/foo trusted.test="02480" # file: dir.2/foo trusted.test="02480" # file: dir.3/foo trusted.test="02480" # file: dir.4/foo trusted.test="02480" # file: dir.5/foo trusted.test="02480" # file: dir.6/foo trusted.test="02480" # file: dir.7/foo trusted.test="02480" ------------ also verified with valgrind -no leaks appeared.