Re: [PATCH 2/3] ceph: add method that forces client to reconnect using new entity addr

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Jun 3, 2019 at 1:24 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.

Furthermore, there are often many applications using the mount (even
with containers) and it's not a sustainable position that any
network/client/cephfs hiccup requires a remount. Also, an application
that fails because of EIO is easy to deal with a layer above but a
remount usually requires grump admin intervention.

-- 
Patrick Donnelly, Ph.D.
He / Him / His
Senior Software Engineer
Red Hat Sunnyvale, CA
GPG: 19F28A586F808C2402351B93C3301A3E258DD79D



[Index of Archives]     [CEPH Users]     [Ceph Large]     [Information on CEPH]     [Linux BTRFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux