<br><br><div class="gmail_quote">On Fri, Mar 22, 2013 at 10:51 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">
<br><br><div class="gmail_quote"><div class="im">On Fri, Mar 22, 2013 at 7:09 AM, Jeff Darcy <span dir="ltr"><<a href="mailto:jdarcy@redhat.com" target="_blank">jdarcy@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The need for some change here is keenly felt<br>
right now as we struggle to fix all of the race conditions that have<br>
resulted from the hasty addition of synctasks to make up for poor<br>
performance elsewhere in that 44K lines of C. </blockquote><div><br></div></div><div>synctasks were not added for performance at all. glusterd being single threaded was incapable of serving volfile in GETSPEC command or assign a port in PORTMAP query when the very process it spawned (glusterfs/glusterfs) would ask glusterd, and wait for the result from glusterd before "finishing daemonizing" (so that a proper exit status be returned), and glusterd would wait for glusterfsd to return before it got back to epoll() and pick the portmap/getspec request -- resulting in a deadlock.</div>
</div></blockquote><div><br></div><div>As I recall more, it was also limiting what a "hook script" could do. A hook couldn't use pretty much any of the gluster cli commands itself (to check peer status, or volume info etc - which would be pretty basic requirements) -- only because glusterd main thread was busy executing the hook script itself and couldn't fullfil new requests arriving on the socket from the script.</div>
<div><br></div><div>The point is that it was never a question of performance - it was to just get basic functionality "working".</div><div><br></div><div>Avati</div></div>