[Gluster-devel] conflicting keys for option eager-lock

Pranith Kumar Karampuri pkarampu at redhat.com
Wed Apr 13 12:11:59 UTC 2016



On 04/13/2016 05:10 PM, Vijay Bellur wrote:
> On 04/13/2016 03:20 AM, Pranith Kumar Karampuri wrote:
>>
>>
>> On 04/13/2016 11:58 AM, Pranith Kumar Karampuri wrote:
>>>
>>>
>>> On 04/13/2016 09:15 AM, Vijay Bellur wrote:
>>>> On 04/08/2016 10:25 PM, Vijay Bellur wrote:
>>>>> Hey Pranith, Ashish -
>>>>>
>>>>> We have broken support for group virt after the following commit in
>>>>> release-3.7:
>>>>>
>>>>> commit 46920e3bd38d9ae7c1910d0bd83eff309ab20c66
>>>>> Author: Ashish Pandey <aspandey at redhat.com>
>>>>> Date:   Fri Mar 4 13:05:09 2016 +0530
>>>>>
>>>>>      cluster/ec: Provide an option to enable/disable eager lock
>>>>>
>>>>>
>>>>
>>>> Thinking more - do we need two different options to control eager
>>>> lock behavior for afr and ec? cluster.eager-lock can be applicable
>>>> for ec too as ec and afr are normally used in a mutually exclusive
>>>> manner. Are we resorting to a different key for glusterd's op-version
>>>> compatibility?
>>>
>>> Tiering breaks all our assumptions, at the  moment we want afr to use
>>> eager-lock where as disperse to not for tiering, so it is better this
>>> way.
>>
>> This is only till we fix the eager-locking behavior in disperse in some
>> cases where it is not learning that other clients are competing for
>> locks. We already have a solution in place. After which both can be
>> enabled for things to work smooth.
>>
>
> Thanks, Pranith. In the interim can we also please fix the volume set 
> help description for disperse.eager-lock?
Yes, that will be done.

Pranith
>
> -Vijay
>



More information about the Gluster-devel mailing list