Bug 1002496
Summary: | [quota] All brick processes got killed, while removing the directory from fuse mount on which quota is set and recreating the same directory, followed by 'quota list' | ||||||
---|---|---|---|---|---|---|---|
Product: | [Red Hat Storage] Red Hat Gluster Storage | Reporter: | SATHEESARAN <sasundar> | ||||
Component: | glusterd | Assignee: | Raghavendra Bhat <rabhat> | ||||
Status: | CLOSED ERRATA | QA Contact: | SATHEESARAN <sasundar> | ||||
Severity: | high | Docs Contact: | |||||
Priority: | high | ||||||
Version: | 2.1 | CC: | asriram, kparthas, rhs-bugs, saujain, shaines, vbellur | ||||
Target Milestone: | --- | Keywords: | ZStream | ||||
Target Release: | --- | ||||||
Hardware: | Unspecified | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | glusterfs-3.4.0.33rhs | Doc Type: | Bug Fix | ||||
Doc Text: |
Previously, when a directory, on which quota limits are set, is deleted from the fuse mount and recreated with the same absolute path leads to quota list command failure due to brick processes crashing. Now, with this update this issue has been fixed.
|
Story Points: | --- | ||||
Clone Of: | Environment: | ||||||
Last Closed: | 2013-11-27 15:35:26 UTC | Type: | Bug | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Attachments: |
|
Description
SATHEESARAN
2013-08-29 10:31:10 UTC
Created attachment 791760 [details]
tar-ed sosreports
Additional Info =============== 1. Volume is fuse mounted on 10.70.36.32 ( RHEL 6.4 ) 2. Mount point - /mnt/distvol 3. All commands are executed from RHS Node - 10.70.37.174 4. sosreports are attached 5. Observation =============== I could see following in brick logs in 10.70.37.174 () <snip> patchset: git://git.gluster.com/glusterfs.git signal received: 11 time of crash: 2013-08-29 09:42:14configuration details: argp 1 backtrace 1 dlfcn 1 fdatasync 1 libpthread 1 llistxattr 1 setfsid 1 spinlock 1 epoll.h 1 xattr.h 1 st_atim.tv_nsec 1 package-string: glusterfs 3.4.0.20rhsquota5 /lib64/libc.so.6[0x3abc432920] /lib64/libc.so.6[0x3abc481321] /usr/lib64/glusterfs/3.4.0.20rhsquota5/xlator/storage/posix.so(posix_make_ancestryfromgfid+0x239)[0x7fd492a97629] /usr/lib64/glusterfs/3.4.0.20rhsquota5/xlator/storage/posix.so(posix_get_ancestry_directory+0xdd)[0x7fd492a913dd] /usr/lib64/glusterfs/3.4.0.20rhsquota5/xlator/storage/posix.so(+0x1b216)[0x7fd492a94216] /usr/lib64/libglusterfs.so.0(dict_foreach+0x45)[0x31de014025] /usr/lib64/glusterfs/3.4.0.20rhsquota5/xlator/storage/posix.so(posix_lookup_xattr_fill+0x85)[0x7fd492a938f5] /usr/lib64/glusterfs/3.4.0.20rhsquota5/xlator/storage/posix.so(posix_lookup+0x871)[0x7fd492a90401] /usr/lib64/libglusterfs.so.0(default_lookup+0x6d)[0x31de01befd] /usr/lib64/glusterfs/3.4.0.20rhsquota5/xlator/features/access-control.so(posix_acl_lookup+0x1a2)[0x7fd4924638c2] /usr/lib64/glusterfs/3.4.0.20rhsquota5/xlator/features/locks.so(pl_lookup+0x222)[0x7fd49224b892] /usr/lib64/glusterfs/3.4.0.20rhsquota5/xlator/performance/io-threads.so(iot_lookup_wrapper+0x12c)[0x7fd492037ebc] /usr/lib64/libglusterfs.so.0(call_resume+0x122)[0x31de030172] /usr/lib64/glusterfs/3.4.0.20rhsquota5/xlator/performance/io-threads.so(iot_worker+0x158)[0x7fd49203c9f8] /lib64/libpthread.so.0[0x3abcc07851] /lib64/libc.so.6(clone+0x6d)[0x3abc4e890d] --------- </snip> https://code.engineering.redhat.com/gerrit/#/c/12036/ fixes the issue. When readlink was done on the gfid handle for a directory (while building the ancestory upon getting a nameless lookup on the gfid) the failure of the readlink call was not handled. The return value of the readlink call was collected in an unsigned variable (readlink returns -1 upon failure). And the return value was not checked. The patch mentioned above fixes the issue. Verified with RHS 2.1 containing glusterfs-3.4.0.33rhs-1.el6rhs Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2013-1769.html |