Re: conflicting keys for option eager-lock

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

 





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.

Pranith

Pranith


Thanks,
Vijay

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

_______________________________________________
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