Whit,<br><br>Genius!<br><br>This morning I set out to remove as many variables as possible to whittle down the repro case as much as possible. I've become pretty good at debugging memory dumps on the Windows side over the years, and even inspected the web processes. Nothing looked out of the ordinary there, just a bunch of threads waiting to get file attribute data from the Gluster share.<br>
<br>So then, to follow your lead, I reduced the Page of Death down from thousands of images to just five. I tried accessing the page, and boom, everything's frozen for minutes. Interesting. So I reduced it to one image, accessed the page, and boom, everything's dead instantly. That one image is a file that doesn't exist.<br>
<br>So now, knowing that GlusterFS is kicking into overdrive fretting about a file it can't find, I decided to eliminate the web server altogether. I opened up Windows Explorer, and typed in a directory that didn't exist, and sure enough, I'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't found, and each one it can't find causes the SMB connection to hang for close to a minute.<br>
<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'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 "thisdirdoesntexist" is in that storage directory along with those 80,000 real subdirs. I know it's a pretty laborious thing for Gluster to piece together a directory listing, and combined with Joseph's recognition of the flood of "getdents", does it seem reasonable that Gluster or Samba is freezing because it's for some reason generating a subdir listing of /storage whenever it can't find one of its subdirs?<br>
<br>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><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't exist, if that makes sense. So in /this/is/a/long/path, if "is" doesn't exist, then Samba will generate a list of subdirs under "/this". And if "/this" has 100,000 immediate subdirs under it, then you're about to experience a world of hurt.<br>
<br>I read some where that FUSE's implementation of readdir() is a blocking operation. If true, the above explanation, plus FUSE's readdir(), are to blame.<br><br>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's side?<br>
<br>Ken<br><br><br><br><div class="gmail_quote">On Sun, Jul 17, 2011 at 10:29 PM, Whit Blauvelt <span dir="ltr"><<a href="mailto:whit.gluster@transpect.com">whit.gluster@transpect.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Sun, Jul 17, 2011 at 10:19:00PM -0500, Ken Randall wrote:<br>
<br>
> (The no such file or directory part is expected since some of the image<br>
> references don't exist.)<br>
<br>
</div>Wild guess on that: Gluster may work harder at files it doesn't find than<br>
files it finds. It's going to look on one side or the other of the<br>
replicated file at first, and if it finds the file deliver it. But if it<br>
doesn't find the file, wouldn't it then check the other side of the<br>
replicated storage to make sure this wasn't a replication error?<br>
<br>
Might be interesting to run a version of the test where all the images<br>
referenced do exist, to see if it's the missing files that are driving up<br>
the CPU cycles.<br>
<font color="#888888"><br>
Whit<br>
<br>
</font></blockquote></div><br>