Hi Xuehan, Fsc need to be revoked if another client is trying to write the file at the same time. because the cache of the “read” client may not be valid any more. > 在 2018年1月17日，上午11:24，Xuehan Xu <xxhdx1985126@xxxxxxxxx> 写道： > > On 17 January 2018 at 10:58, Xuehan Xu <xxhdx1985126@xxxxxxxxx> wrote: >> On 17 January 2018 at 10:06, Yan, Zheng <ukernel@xxxxxxxxx> wrote: >>> On Tue, Jan 16, 2018 at 5:06 PM, Xuehan Xu <xxhdx1985126@xxxxxxxxx> wrote: >>>> Hi, everyone. >>>> >>>> In our online cephfs, we occasionally encounter the error "Client. >>>> isn't responding to mclientcaps", the client kernel we are using is >>>> centos's "3.10.0-514". >>> >>> Is the error persistent and just temporary ? >>> >> >> It's temporary, but lasts for about 1.5 minutes, and the cephfs >> cluster is under no heavy load. >> Thanks:-) > > By the way, in our logs, there is such statements: "client.4607906 > isn't responding to mclientcaps(revoke), ino 0x10000001d30 pending > pAsLsXsFr issued pAsLsXsFscr, sent 62.743469 seconds ago" > > It seems that "Fscr" is all read capabilities, and "Fr" is all read > capabilities, so it seems that the "issued" caps doesn't need to be > revoked. Is this right? > -- > 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 -- 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
