[Gluster-devel] GF_FOP_IPC changes

Pranith Kumar Karampuri pkarampu at redhat.com
Wed Jun 24 14:44:25 UTC 2015



On 06/24/2015 07:44 PM, Soumya Koduri wrote:
>
>
> On 06/24/2015 10:14 AM, Krishnan Parthasarathi wrote:
>>
>>
>> ----- Original Message -----
>>> I've been looking at the recent patches to redirect GF_FOP_IPC to an 
>>> active
>>> subvolume instead of always to the first.  Specifically, these:
>>>
>>>     http://review.gluster.org/11346 for DHT
>>>     http://review.gluster.org/11347 for EC
>>>     http://review.gluster.org/11348 for AFR
>>>
>>> I can't help but wonder if there's a simpler and more generic way to 
>>> do this,
>>> instead of having to do this in a translator-specific way each time 
>>> - then
>>> again for NSR, or for a separate tiering translator, and so on.  For 
>>> example
>>> what if each translator had a first_active_child callback?
>>>
>>>     xlator_t * (*first_active_child) (xlator_t *parent);
>>>
>>> Then default_ipc could invoke this, if it exists, where it currently 
>>> invokes
>>> FIRST_CHILD.  Each translator could implement a bare minimum to 
>>> select a
>>> child, then "step out of the way" for a fop it really wasn't all that
>>> interested in to begin with.  Any thoughts?
>>
>> We should do this right away. This change doesn't affect external 
>> interfaces.
>> we should be bold and implement the first solution. Over time we 
>> could improve
>> on this.
>
> +1. It would definitely ease the implementation of many such fops 
> which have to default to first active child. We need not keep track of 
> all the fops which may get affected with new clustering xlators being 
> added.
I haven't seen the patches yet. Failures can happen just at the time of 
winding, leading to same failures. It at least needs to have the logic 
of picking next_active_child. EC needs to lock+xattrop the bricks to 
find bricks with good copies. AFR needs to perform getxattr to find good 
copies. Just giving more information to see if it helps.

Pranith
>
> Thanks,
> Soumya
>
>
>>



More information about the Gluster-devel mailing list