Re: conflicting keys for option eager-lock

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

 



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@xxxxxxxxxx>
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?

-Vijay

_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-devel



[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