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. 2. tier use case. This normally has a dht over dht and there might be enough cases where double locks might be attempted. Of course, the problem can be solved by tier and dht acquiring locks in different domain (apart from using global lk-owner solution). The need for whether locks should conflict or not even in a single call-stack might be very well use case dependent and even if there is a need for no-conflict there are other ways of achieving it (like a communication in xdata etc). What are your thoughts on having a per-stack global lk-owner (like frame->root->unique), that remains constant throughout the life-time of the call even when the call traverses through various processes like mount, brick, aggregators (quotad) etc? [1] http://review.gluster.org/11880 regards, Raghavendra. _______________________________________________ Gluster-devel mailing list [email protected] http://www.gluster.org/mailman/listinfo/gluster-devel
