> Hmm, that makes some sense but is sad. I think to resolve this we’d > need the MDS to recognize “repetitions” of the same op type that can > be serviced in a single lock operation for essentially no extra > (locking) cost, but I’m not sure how we’d integrate that with the > capability locking going on. > I guess that when we do locking operations, if they are a single > request and don't involve giving the client caps, maybe we could stick > stick any requests that require the same set of locks on a shared data > structure? And then run through them all when we get granted locks and > reply to those requests? That may not involve any real fairness > tradeoffs, as long as we're careful to only do stuff that doesn't > require extra effort (beyond queueing up the message send). > > But I haven't looked at the data structures enough lately to have any > idea if something like this is really feasible. > -Greg Hi, Greg and Zheng I've just submitted several patches(listed as follows) that implements getattr/lookup requests batch reply in MDS and getattr/lookup/sync_read requests aggregation in kernel client. Please take a look, when you are free:-) Thanks. http://tracker.ceph.com/issues/36609 http://tracker.ceph.com/issues/36608