On 03/27/2016 11:57 PM, Raghavendra Gowdappa wrote:
Hi all,
There are some use cases where having a lock-owner which is constant for the
entire call-stack would be helpful. The use-cases normally have a pattern where
a single call visits a translator more than once in its life-time. Some
examples of this pattern are:
1. directory renaming in dht with quota enabled. Since quota-enforcer does a
lookup to quotad in the course of rename, dht is visited twice in the lifetime
of renamedir. Now, if in both visits, dht needs some synchronization and
decides to acquire an inode/entrylk, this results in a deadlock (see comments
on [1]). However, if both instances use same lock-owner deadlock won't ensue.
quotad is a read only client that aggregates values from various bricks
that make up a volume. Should it be even involved in synchronization of
any form? In order to not be involved in afr's self-healing quotad does
get spawned with options to disable client side healing.
-Vijay
_______________________________________________
Gluster-devel mailing list
[email protected]
http://www.gluster.org/mailman/listinfo/gluster-devel
