On 8 February 2018 at 15:10, Xuehan Xu <xxhdx1985126@xxxxxxxxx> wrote: > Hi, everyone. > > Actually, in our case, the whole procedure of a single run of > "getattr" ops processing is this: > > 1. The "finish" phase of the previous "getattr" op processing turn the > target inode's filelock state into LOCK_SYNC_MIX if its current state > is LOCK_SYNC; > 2. mds blocks all other "getattr" operations when the target inode's > filelock state is LOCK_SYNC_MIX, and wait for all clients to release > caps that are not allowed in LOCK_MIX; > 3. When all clients release those not allowed caps, the inode's > filelock state is turned in to LOCK_MIX; > 4. A new "getattr" op is dispatched to be processed, during which the > inode's filelock state is turned back to LOCK_SYNC and the "getattr" > op is processed successfully; > > If the next op that is to be dispatched to be processed is, again, a > "getattr", the whole procedure would be repeated. In our case, the > waiting of the mds for all clients to release caps that are not > allowed in state LOCK_MIX could take several hundreds of milliseconds, > which means only a few "getattr" requests can be processed per second. > And because the "getattr" operation is the mostly issued request in > our case, the above procedure can repeat so many times that the > response time of the process of a single "getattr" request can take > 40+ seconds as they have to wait for their previous "getattr" ops to > be processed first, and in the meantime, the "setattr" operations that > are issued by the writing client can hardly get the chance to be > processed I'm now trying to read the related source code, however, I found it a little hard to understand. What does the MDSCacheObject's auth_pin method mean? Does it mean that the MDSCacheObject cannot be evicted from the in memory cache? -- 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
