Hi Brent,<br><br><div class="gmail_quote">On Wed, Jan 14, 2009 at 6:56 PM, Brent A Nelson <span dir="ltr"><<a href="mailto:brent@phys.ufl.edu">brent@phys.ufl.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">On Wed, 14 Jan 2009, Vikas Gorur wrote:<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
As for io-threads above/below unify, there is not much to be gained by<br>
using io-threads on the client side, since there are no slow<br>
operations on the client side (just a straight code path from the<br>
application to the server). Using it on the server makes sense because<br>
it lets GlusterFS do other useful work while one thread is waiting for<br>
a read/write from/to the underlying filesystem finishes.<br>
<br>
</blockquote>
<br></div>
I found io-threads on the client to be a major gain. When the client is very busy with io tasks, io-threads seems to eliminate latency in metadata operations (e.g., ls doesn't hang for ages). It made the client feel much more responsive.</blockquote>
<div><br>Yes. But with 2.0, Non-blocking I/O is introduced. Hence the client thread will not be blocked on I/O operations.<br><br>regards,<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
<br>
Thanks,<br><font color="#888888">
<br>
Brent</font><div><div></div><div class="Wj3C7c"><br>
<br>
<br>
_______________________________________________<br>
Gluster-devel mailing list<br>
<a href="mailto:Gluster-devel@nongnu.org" target="_blank">Gluster-devel@nongnu.org</a><br>
<a href="http://lists.nongnu.org/mailman/listinfo/gluster-devel" target="_blank">http://lists.nongnu.org/mailman/listinfo/gluster-devel</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Raghavendra G<br><br>