The issue was that a dentry in the inode table was skewed in a way that the dentry of a file occured before its parent. So, the entry was like parent > child > parent. This triggered an infinite loop in inode table causing the loc>Path to be NULL and as there was no way to handle this NULL path, a crash dump was triggered. This dentry issue in the inode table was caused by a race in readdirp. I followed simple steps as suggested : 1. Create a 3 level folder structure. /fuse_mnt1/test_1186657/bug1/sub_dir 2. cd to the folder and start creating and deleting the files. while true; do touch a; rm -f a; done 3. From the other mount point, start a lookup: while true; do ls -lR > /dev/null; done 4. I started this file and link creation from multiple terminals for different files on different mount points. The idea was to try and create a race in readdirp while entries are being made and deleted from the inode table. Didn't see the crash neither the error messages in the logs files. Note: I could see following quota messages on the log files: ==> /var/log/glusterfs/bricks/rhs-brick1-gv0.log <== [2015-03-10 15:22:47.771144] W [quota.c:1773:quota_unlink_cbk] 0-gv0-quota: quota context not set in inode (gfid:51a0154d-318c-42dc-9d31-12e3eaa13d15) ==> /var/log/glusterfs/bricks/rhs-brick3-gv0.log <== [2015-03-10 15:22:47.774715] W [quota.c:1773:quota_unlink_cbk] 0-gv0-quota: quota context not set in inode (gfid:51a0154d-318c-42dc-9d31-12e3eaa13d15) Marking the bug verified.
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. https://rhn.redhat.com/errata/RHBA-2015-0682.html