Re: Glusterd: A New Hope

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On Fri, Mar 22, 2013 at 10:51 AM, Anand Avati <anand.avati@xxxxxxxxx> wrote:


On Fri, Mar 22, 2013 at 7:09 AM, Jeff Darcy <jdarcy@xxxxxxxxxx> wrote:
The need for some change here is keenly felt
right now as we struggle to fix all of the race conditions that have
resulted from the hasty addition of synctasks to make up for poor
performance elsewhere in that 44K lines of C.

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.

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.

The point is that it was never a question of performance - it was to just get basic functionality "working".

Avati

[Index of Archives]     [Gluster Users]     [Ceph Users]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux