| Summary: | getxattr() on a directory sometimes returns junk | ||
|---|---|---|---|
| Product: | [Community] GlusterFS | Reporter: | Vikas Gorur <vikas> |
| Component: | distribute | Assignee: | shishir gowda <sgowda> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | urgent | ||
| Version: | 3.1.2 | CC: | amarts, gluster-bugs, lakshmipathi, nsathyan, vijay |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | All | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | Type: | --- | |
| Regression: | RTA | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
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. |
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.