Please fine responses inline.<br><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br>So now, knowing that GlusterFS is kicking into overdrive fretting about a file it can&#39;t find, I decided to eliminate the web server altogether.  I opened up Windows Explorer, and typed in a directory that didn&#39;t exist, and sure enough, I&#39;m unable to navigate through the share in another Explorer window until it finally responds again a minute later.  I think the Page of Death was exhibiting such a massive death (e.g. only able to respond again upwards of five minutes later) because it was systematically trying to access several files that weren&#39;t found, and each one it can&#39;t find causes the SMB connection to hang for close to a minute.<br>
</blockquote><div><br></div><div><br></div><div>Gluster does not really care if a file is not found. It just looks up the filename on all servers and returns -ENOENT. End of story for Gluster. What&#39;s happening here is that Samba is &#39;searching&#39; through all filenames in the directory to match some other filename with strcasecmp() to provide a case-insensitive match to the user.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>I feel like this is a bit of major progress toward pinpointing the problem for a possible resolution.  Here are some additional details that may help:<br><br>The GlusterFS directory in question, /storage, has about 80,000 subdirs in it.  As such, I&#39;m using ext4 to overcome the subdir limitations of ext3.  The non-existent image file that is able to cause everything to freeze exists in a directory, /storage/thisdirdoesntexist/images/blah.gif, where &quot;thisdirdoesntexist&quot; is in that storage directory along with those 80,000 real subdirs.  I know it&#39;s a pretty laborious thing for Gluster to piece together a directory listing, and combined with Joseph&#39;s recognition of the flood of &quot;getdents&quot;, does it seem reasonable that Gluster or Samba is freezing because it&#39;s for some reason generating a subdir listing of /storage whenever it can&#39;t find one of its subdirs?<br>
</blockquote><div><br></div><div><br></div><div>Yes, it is samba searching around for the case insensitive match.</div><div> </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
As another test, if I access a file inside a non-existent subdir of a dir that only has five subdirs, and nothing freezes.<br></blockquote><div><br></div><div><br></div><div>That is because iterating over 5 names to determine non existence of a case insensitive match is trivially fast.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br>So the freezing seems to be a function of the number of subdirectories that are siblings of the first part of the path that doesn&#39;t exist, if that makes sense.  So in /this/is/a/long/path, if &quot;is&quot; doesn&#39;t exist, then Samba will generate a list of subdirs under &quot;/this&quot;.  And if &quot;/this&quot; has 100,000 immediate subdirs under it, then you&#39;re about to experience a world of hurt.<br>

<br>I read some where that FUSE&#39;s implementation of readdir() is a blocking operation.  If true, the above explanation, plus FUSE&#39;s readdir(), are to blame.<br></blockquote><div><br></div><div>What do you mean by that. FUSE&#39;s readdir() is as blocking or unblocking as the rest of its open/create/getattr/setattr etc. What you probably meant was that the fuse kernel module does not cache dirents?</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">And I am therefore up a creek.  It is not feasible to enforce the system to only have a few subdirs at any given level to prevent the lockup.  Unless somebody, after reading this novel, has some ideas for me to try.  =)  Any magical ways to not get FUSE to block, or any trickery on Samba&#39;s side?</blockquote>
<div><br></div><div>It is not FUSE blocking that is your problem. You need a quicker trick to achieve case insensitivity.</div><div><br></div><div>Avati</div></div>