----- Original Message ----- > From: "Vijay Bellur" <vbellur@xxxxxxxxxx> > To: "Raghavendra Gowdappa" <rgowdapp@xxxxxxxxxx>, "Gluster Devel" <gluster-devel@xxxxxxxxxxx> > Sent: Monday, March 28, 2016 9:35:26 AM > Subject: Re: Need for a per call stack global lock-owner > > 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. In that case, dht too can have options to change its behaviour wrt healing, which is also sufficient solution for the problem at hand. > > -Vijay > _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel
