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 -- 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
