On Tue, 2021-10-12 at 15:09 +0800, Yan, Zheng wrote: > > > On Mon, Oct 11, 2021 at 6:48 PM Jeff Layton <jlayton@xxxxxxxxxx> > wrote: > > On Mon, 2021-10-11 at 11:37 +0800, Yan, Zheng wrote: > > > > > > > > > On Tue, Oct 5, 2021 at 6:17 PM Jeff Layton <jlayton@xxxxxxxxxx> > > wrote: > > > > On Tue, 2021-10-05 at 10:00 +0200, Ilya Dryomov wrote: > > > > > On Thu, Sep 30, 2021 at 7:03 PM Jeff Layton > > > > > <jlayton@xxxxxxxxxx> > > > > wrote: > > > > > > > > > > > > Currently when mounting, we may end up finding an existing > > > > superblock > > > > > > that corresponds to a blocklisted MDS client. This means > > > > > > that > > > > > > the > > > > new > > > > > > mount ends up being unusable. > > > > > > > > > > > > If we've found an existing superblock with a client that is > > > > already > > > > > > blocklisted, and the client is not configured to recover on > > its > > > > own, > > > > > > fail the match. > > > > > > > > > > > > While we're in here, also rename "other" to the more > > > > > > conventional > > > > "fsc". > > > > > > > > > > > > > > > > > > > Note: we have similar issue for forced umounted superblock > > > > > > > True... > > > > There is a small window of time between when ->umount_begin runs and > > generic_shutdown_super happens. Between that period, you could match > > a > > superblock that's been forcibly umounted and is on the way to being > > detached from the tree. > > > > > I mean set fsc->mount_state to CEPH_MOUNT_SHUTDOWN, but failed to > fully shutdown (still referenced) the superblock > Good point. We could have a superblock that is still extant but that was forcibly unmounted and detached. I'll send a v3 patch that incorporates that case as well. Thanks, -- Jeff Layton <jlayton@xxxxxxxxxx>
