On Mon, Feb 5, 2018 at 11:09 PM, Yan, Zheng <ukernel@xxxxxxxxx> wrote: > On Tue, Feb 6, 2018 at 2:55 PM, Xuehan Xu <xxhdx1985126@xxxxxxxxx> wrote: >>>> >>>> Thanks, Zheng Yan:-) >>>> >>>> In our case, there is only one client want the "Fw" capability, most >>>> of the clients just needs "Fscr". However, as LOCK_MIX state allows >>>> only "Frwl", CInode::filelock had to wait in LOCK_SYNC_MIX state for >>>> those tens of READ clients to release "Fsc" caps, which led to the >>>> long wait and inefficient processing of getattr requests. We think >>>> waiting for clients to release "Fsc" in this case might not be >>>> necessary, is this right? >>> >>> Oh, sorry, in our case, the transition of CInode::filelock's state >>> from LOCK_SYNC to LOCK_SYNC_MIX is done in the "finish" phase of a >>> getattr request when there are clients who want the "Fw" cap at the >>> time. So I think, this should be the mds waiting for READ clients to >>> release "Fsc" so that it can issue "Fw" to the writing client. >> >> And, since "Fw" is still not issued to the writing client yet in the >> LOCK_SYNC_MIX state, it seems that getattr requests should be >> processed instead of blocked in this state, is this right? > > this will starve writer if there are lots of getattr I've been following this discussion casually and am a bit confused. The Client will happily send off an explicit getattr request if it doesn't have enough capabilities to answer it locally. Is the problem here that the MDS is not answering all pending CEPH_MDS_OP_GETATTR requests in one go? (Which I suppose it doesn't really have a way of doing, if they haven't all been processed into interior pending locks — but I think they should have gotten there if caps are being recalled?) Or are the clients for some reason requesting capabilities instead of the single getattr message? -Greg -- 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
