Also, I don't think this lock has big impact to performance since it is already sharded to index level. I tried with reader/writer implementation of this lock (logic will be somewhat similar to your state concept) and not getting any benefit .
Thanks & Regards Somnath -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Gregory Farnum Sent: Tuesday, September 30, 2014 10:24 AM To: Nicheal Cc: ceph-devel Subject: Re: why index (collectionIndex) need a lock? On Tue, Sep 30, 2014 at 12:08 AM, Nicheal <[email protected]> wrote: > Dear develops, > > I go through the files (hashIndex, LFNIndex and CollectionIndex), I > cannot find any parameters need to grasp a lock. And basically, > (hashIndex, LFNIndex and CollectionIndex) is used to manage a > collection of objects. > > Thus, just in one case, when the spilt or merge is on going, then > lookup() path function is called to get the object path. It may obtain > a wrong path, right? > > If so, why not using a state parameter in the class CollectionIndex or > HashIndex indicating the current state of this collection (split, > merge on going or none) and grasp a lock when the state changes. Why > always lock the index before lookup() path or lfn_find()? > > Any other reasons? Well, you've just named why we have the lock — it's to prevent multiple users simultaneously making changes to the *filesystem* that we can't handle. In particular, no simultaneous ops can run against the same Collection. This is to prevent situations where a reader comes in and builds up the path for an object it needs to look at, then a writer creates a new file which initiates collection split and the reader's path is suddenly invalid. -Greg Software Engineer #42 @ http://inktank.com | http://ceph.com -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html ________________________________ PLEASE NOTE: The information contained in this electronic mail message is intended only for the use of the designated recipient(s) named above. If the reader of this message is not the intended recipient, you are hereby notified that you have received this message in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify the sender by telephone or e-mail (as shown above) immediately and destroy any and all copies of this message in your possession (whether hard copies or electronically stored copies).
