On Tue, Aug 16, 2022 at 3:14 PM Vladimir Brik <vladimir.brik@xxxxxxxxxxxxxxxx> wrote: > > Hello > > I'd like to understand what is the proper/safe way to > recover when a cephfs client becomes blocklisted by the MDS. > > The man page of mount.ceph talks about recover_session=clean > option, but it has the following text I am not sure I am > interpreting correctly: > > "After reconnect, file locks become stale because the MDS > loses track of them. If an inode contains any stale file > locks, read/write on the inode is not allowed until > applications release all stale file locks." > > Does "application" in this context refer to the cephfs > kernel client or a user space process? > Hmm, I haven't thought about this before. But the application asks for locks, and those locks need to get released. The kernel client can't do it on its own. > Does this mean that if the application terminates while the > client is blocklisted without releasing locks, the locked > inodes (and the files they belong to) become inaccessible > forever? > > Is reboot the only safe way to deal with blocklisting, > assuming applications were writing to files when it happened? Basically, yes. When you're disconnected, changes can be made by other clients without regard to any buffered changes that the disconnected client may have made. And then if a reconnect is forced, the previously-disconnected node just writes out whatever it has, which may roll back data from other clients that were alive the whole time. There are ways to narrow that window that we incrementally work on, but that fundamental conflict will always be there. -Greg > > > Thanks very much > > Vlad > _______________________________________________ > ceph-users mailing list -- ceph-users@xxxxxxx > To unsubscribe send an email to ceph-users-leave@xxxxxxx > _______________________________________________ ceph-users mailing list -- ceph-users@xxxxxxx To unsubscribe send an email to ceph-users-leave@xxxxxxx
 |