On Mon, Jun 3, 2019 at 10:23 PM Gregory Farnum <gfarnum@xxxxxxxxxx> wrote:
>
> On Mon, Jun 3, 2019 at 1:07 PM Ilya Dryomov <idryomov@xxxxxxxxx> wrote:
> > Can we also discuss how useful is allowing to recover a mount after it
> > has been blacklisted? After we fail everything with EIO and throw out
> > all dirty state, how many applications would continue working without
> > some kind of restart? And if you are restarting your application, why
> > not get a new mount?
> >
> > IOW what is the use case for introducing a new debugfs knob that isn't
> > that much different from umount+mount?
>
> People don't like it when their filesystem refuses to umount, which is
> what happens when the kernel client can't reconnect to the MDS right
> now. I'm not sure there's a practical way to deal with that besides
> some kind of computer admin intervention. (Even if you umount -l, that
> by design doesn't reply to syscalls and let the applications exit.)
Well, that is what I'm saying: if an admin intervention is required
anyway, then why not make it be umount+mount? That is certainly more
intuitive than an obscure write-only file in debugfs...
We have umount -f, which is there for tearing down a mount that is
unresponsive. It should be able to deal with a blacklisted mount, if
it can't it's probably a bug.
Thanks,
Ilya
