Hi Zheng, Thanks for the input. So we dont client to reconnect due to dirty metadata? Does client drop dirty data(page cached data) when reconnect get denied and try tro re-open session? And would you mind pointing the commit/kernel version considered recent enough with re-open session? We are on CentOS 7.3 (3.10.0-514.21.2.el7.x86_64) but seems not the behavior. Xiaoxi 2017-10-13 21:59 GMT+08:00 Yan, Zheng <ukernel@xxxxxxxxx>: > On Fri, Oct 13, 2017 at 2:10 PM, Xiaoxi Chen <superdebuger@xxxxxxxxx> wrote: >> >> resend with plain txt >> >> 2017-10-13 10:56 GMT+08:00 Xiaoxi Chen <superdebuger@xxxxxxxxx>: >> > Hi, >> > >> > We sometimes seen client (fs kernel) get evicted by MDS and try to >> > reconnect, even we set mds_session_blacklist_on_evict = True, client still >> > cannot reconnect due to below code: >> > >> > if (!mds->is_reconnect() && mds->get_want_state() == >> > CEPH_MDS_STATE_RECONNECT) { >> > dout(10) << " we're almost in reconnect state (mdsmap delivery race?); >> > waiting" << dendl; >> > mds->wait_for_reconnect(new C_MDS_RetryMessage(mds, m)); >> > return; >> > } >> > >> > Could someone share any insight on why MDS only accept reconnect in >> > reconnect state? and how, if the client is get evicted , can automatically >> > recovered? note that remount is usually impossible as umount will always >> > hang(due to cannot talk to mds). >> > > > If reconnect get denied, unflushed dirty metadata on client get lost. > > If mds_session_blacklist_on_evict is set to FALSE, recent version kernel client > should re-open session automatically after reconnect get denied. For > fuse client, > client_reconnect_stale need to be set to true. > > FYI: 'umount -f' works for evicted client. > > > >> >> > >> > >> > Xiaoxi >> -- >> 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