On Tue, Sep 30, 2014 at 12:08 AM, Nicheal <zay11022@xxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
