[ Please keep stuff on the list; we don't do private emails and you'll get faster responses. ] I don't know for this particular case, but I think it's just an invariant for all FileStore operations. There's a lot of random stuff that can go into the omap; it's user-accessible. -Greg Software Engineer #42 @ http://inktank.com | http://ceph.com On Tue, Oct 7, 2014 at 7:37 PM, Nicheal <zay11022@xxxxxxxxx> wrote: > Thanks, I got your concept. > I find that the Index Ref will be obtained before omap_setkeys (called > function lfn_find). However, the path is not used in function > omap_setkeys. So why we prevent the Collection (merge or split) when > modifying omap keys? Actually, the information in omap is pg_log, > pg_info, and sometimes, object XATTR, right? > > 2014-10-01 1:23 GMT+08:00 Gregory Farnum <greg@xxxxxxxxxxx>: >> 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
