Hi I&#39;m running into a rather strange and frustrating bug and wondering if anyone on the mailing list might have some insight about what might be causing it. I&#39;m running a cluster of two dozen nodes, where the processing nodes are also the gluster bricks (using the SLURM resource manager). Each node has the glusters mounted natively (not NFS). All nodes are using v3.2.7. Each job in the node runs a shell script like so:<div>
<br></div><div><font face="courier new, monospace">containerDir=$1</font></div><div><font face="courier new, monospace">groupNum=$2</font></div><div><font face="courier new, monospace">mkdir -p $containerDir</font></div><div>
<font face="courier new, monospace">./generateGroupGen.py $groupNum &gt;$containerDir/$groupNum.out</font></div><div><br></div><div>Then run the following jobs:</div><div><br></div><div><font face="courier new, monospace">runGroupGen [glusterDirectory] 1</font></div>
<div><font face="courier new, monospace">runGroupGen [glusterDirectory] 2</font></div><div><font face="courier new, monospace">runGroupGen [glusterDirectory] 3</font></div><div><font face="courier new, monospace">...</font></div>
<div><br></div><div>Typically about 200 jobs launch within milliseconds of each other so the glusterfs/fuse directory system receives a large number of simultaneous create directory and create file system calls within a very short time.</div>
<div><br></div><div>Some of the output files inside the directory have a file that exists but no output. When this occurs it is always the case that either all jobs on a node behave normally or all fail to produce output. It should be noted that there are no error messages generated by the processes themselves, and all processes on the no-output node return with no error code. In that sense the failure is silent, but corrupts the data, which is dangerous. The only indication of error are errors (on the no output nodes) in the /var/log/distrib-glusterfs.log of the form:</div>
<div><br></div><div><div><font face="courier new, monospace">[2013-02-18 05:55:31.382279] E [client3_1-fops.c:2228:client3_1_lookup_cbk] 0-volume1-client-16: remote operation failed: Stale NFS file handle</font></div><div>
<font face="courier new, monospace">[2013-02-18 05:55:31.382302] E [client3_1-fops.c:2228:client3_1_lookup_cbk] 0-volume1-client-17: remote operation failed: Stale NFS file handle</font></div><div><font face="courier new, monospace">[2013-02-18 05:55:31.382327] E [client3_1-fops.c:2228:client3_1_lookup_cbk] 0-volume1-client-18: remote operation failed: Stale NFS file handle</font></div>
<div><font face="courier new, monospace">[2013-02-18 05:55:31.640791] W [inode.c:1044:inode_path] (--&gt;/usr/lib/glusterfs/3.2.7/xlator/mount/fuse.so(+0xe8fd) [0x7fa8341868fd] (--&gt;/usr/lib/glusterfs/3.2.7/xlator/mount/fuse.so(+0xa6bb) [0x7fa8341826bb] (--&gt;/usr/lib/glusterfs/3.2.7/xlator/mount/fuse.so(fuse_loc_fill+0x1c6) [0x7fa83417d156]))) 0-volume1/inode: no dentry for non-root inode -69777006931: 0a37836d-e9e5-4cc1-8bd2-e8a49947959b</font></div>
<div><font face="courier new, monospace">[2013-02-18 05:55:31.640865] W [fuse-bridge.c:561:fuse_getattr] 0-glusterfs-fuse: 2298073: GETATTR 140360215569520 (fuse_loc_fill() failed)</font></div><div><font face="courier new, monospace">[2013-02-18 05:55:31.641672] W [inode.c:1044:inode_path] (--&gt;/usr/lib/glusterfs/3.2.7/xlator/mount/fuse.so(+0xe8fd) [0x7fa8341868fd] (--&gt;/usr/lib/glusterfs/3.2.7/xlator/mount/fuse.so(+0xa6bb) [0x7fa8341826bb] (--&gt;/usr/lib/glusterfs/3.2.7/xlator/mount/fuse.so(fuse_loc_fill+0x1c6) [0x7fa83417d156]))) 0-volume1/inode: no dentry for non-root inode -69777006931: 0a37836d-e9e5-4cc1-8bd2-e8a49947959b</font></div>
<div><font face="courier new, monospace">[2013-02-18 05:55:31.641724] W [fuse-bridge.c:561:fuse_getattr] 0-glusterfs-fuse: 2298079: GETATTR 140360215569520 (fuse_loc_fill() failed)</font></div></div><div><font face="courier new, monospace">...</font></div>
<div><br></div><div>Sometimes on these events, and sometimes not, there will also be logs (on both normal and abnormal nodes) of the form:</div><div><br></div><div><font face="courier new, monospace">[2013-02-18 03:35:28.679681] I [dht-common.c:525:dht_revalidate_cbk] 0-volume1-dht: mismatching layouts for /inSample/pred/20110831</font></div>
<div><br></div><div>I understand from reading the mailing list that both the dentry errors and the mismatched layout errors are both non-fatal warnings and that the metadata will become internally consistent regardless. But these errors only happen on times when I&#39;m slamming the glusterfs system with the creation of a bunch of small files in a very short burst like I described above. So their presence seems to be related to the error.</div>
<div><br></div><div>I think the issue is almost assuredly related to the delayed propagation of glusterfs directory metadata. Some nodes are creating directory simultaneous to other nodes and the two are producing inconsistencies with regards to the dht layout information. My hypothesis is that when Node A is still writing that the process to resolve the inconsistencies with and propagate the metadata from Node B is rendering the location that Node A is writing to disconnected from its supposed path. (And hence the no dentry errors). </div>
<div><br></div><div>I&#39;ve taken some effort to go through the glusterfs source code, particularly the dht related files. The way dht normalizes anomalies could be the problem, but I&#39;ve failed to find anything specific.</div>
<div><br></div><div>Has anyone else run into a problem like this, or have insight about what might be causing it or how to avoid it?</div>