<div dir="ltr">Are the ls commands (which list partially, or loop and die of ENOMEM eventually) executed on an NFS mount or FUSE mount? Or does it happen on both?<div><br></div><div style>Avati</div></div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Fri, Jun 14, 2013 at 11:14 AM, Anand Avati <span dir="ltr"><<a href="mailto:anand.avati@gmail.com" target="_blank">anand.avati@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote"><div class="im">On Fri, Jun 14, 2013 at 10:04 AM, John Brunelle <span dir="ltr"><<a href="mailto:john_brunelle@harvard.edu" target="_blank">john_brunelle@harvard.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Thanks, Jeff! I ran readdir.c on all 23 bricks on the gluster nfs<br>
server to which my test clients are connected (one client that's<br>
working, and one that's not; and I ran on those, too). The results<br>
are attached.<br>
<br>
The values it prints are all well within 32 bits, *except* for one<br>
that's suspiciously the max 32-bit signed int:<br>
<br>
$ cat readdir.out.* | awk '{print $1}' | sort | uniq | tail<br>
0x000000000000fd59<br>
0x000000000000fd6b<br>
0x000000000000fd7d<br>
0x000000000000fd8f<br>
0x000000000000fda1<br>
0x000000000000fdb3<br>
0x000000000000fdc5<br>
0x000000000000fdd7<br>
0x000000000000fde8<br>
0x000000007fffffff<br>
<br>
That outlier is the same subdirectory on all 23 bricks. Could this be<br>
the issue?<br>
<br>
Thanks,<br>
<br>
John</blockquote><div><br></div><div><br></div></div><div>0x7ffffffff is the EOF marker. You should find that as last entry in _every_ directory.</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>Avati</div>
</font></span></div></div></div>
</blockquote></div><br></div>