<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 24, 2017 at 9:01 AM, Krist van Besien <span dir="ltr">&lt;<a href="mailto:krist@redhat.com" target="_blank">krist@redhat.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div>Hi<br></div><div>This is gluster 3.8.4. Volume options are out of the box. Sharding is off (and I don&#39;t think enabling it would matter)<br></div><div><br></div>I haven&#39;t done much performance tuning. For one thing, using a simple script that just creates files I can easily flood the network, so I don&#39;t expect a performance issue.<br></div><br></div>The problem we see is that after a certain time the fuse clients completely stop accepting writes. Something is preventing the application to write after a while. <br></div>We see this on the fuse client, but not when we use nfs. So the question I am interested in seeing an answer too is in what way is nfs different from fuse that could cause this.</div><div><br></div><div>My suspicion is it is locking related.</div><span class="HOEnZb"><font color="#888888"><div><br></div></font></span></div></blockquote></div><br></div><div class="gmail_extra">Would it be possible to obtain a statedump of the native client when the application becomes completely unresponsive? A statedump can help in understanding operations within the gluster stack. Log file of the native client might also offer some clues.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Regards,</div><div class="gmail_extra">Vijay</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div></div>