[Gluster-devel] Regarding multi-threaded epoll and notify
Jeff Darcy
jdarcy at redhat.com
Thu Jan 29 12:50:44 UTC 2015
> With the addition of multi-threaded epoll functionality,
> handling CHILD_UP/CHILD_DOWN in cluster xlators gets tricky. i.e. Let us
> assume one of the bricks in replication is down while the other one is
> up. Now if in parallel the brick that went down comes up and the one
> that is up goes down, there is a possibility for wrong CHILD_UP/DOWN to
> go to parent of afr, similar for dht as well. One way to fix it is each
> cluster xlator handle this correctly but it entails calling 'notify'
> inside mutex locks to the parent translator. Another way to fix it is
> that we should add the CHILD_UP/CHILD_DOWN related epoll events from rpc
> layer into a queue and have a dedicated thread process these events,
> something similar to how timer thread processes events. If this gets in
> we get best of both worlds where CHILD_UP/DOWN will be single threaded
> so xlators don't have to worry about it, while the fops get
> multi-threaded behaviour.
>
> I like the second approach. What do you guys suggest?
I like the queue/worker approach too.
More information about the Gluster-devel
mailing list