[Gluster-devel] Regarding multi-threaded epoll and notify

Pranith Kumar Karampuri pkarampu at redhat.com
Thu Jan 29 11:08:30 UTC 2015


hi,
         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?

Pranith


More information about the Gluster-devel mailing list