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 6:51 AM Yan, Zheng <ukernel@xxxxxxxxx> wrote:
>
> On Fri, May 31, 2019 at 10:20 PM Ilya Dryomov <idryomov@xxxxxxxxx> wrote:
> >
> > On Fri, May 31, 2019 at 2:30 PM Yan, Zheng <zyan@xxxxxxxxxx> wrote:
> > >
> > > echo force_reconnect > /sys/kernel/debug/ceph/xxx/control
> > >
> > > Signed-off-by: "Yan, Zheng" <zyan@xxxxxxxxxx>
> >
> > Hi Zheng,
> >
> > There should be an explanation in the commit message of what this is
> > and why it is needed.
> >
> > I'm assuming the use case is recovering a blacklisted mount, but what
> > is the intended semantics?  What happens to in-flight OSD requests,
> > MDS requests, open files, etc?  These are things that should really be
> > written down.
> >
> got it
>
> > Looking at the previous patch, it appears that in-flight OSD requests
> > are simply retried, as they would be on a regular connection fault.  Is
> > that safe?
> >
>
> It's not safe. I still thinking about how to handle dirty data and
> in-flight osd requests in the this case.

Can we figure out the consistency-handling story before we start
adding interfaces for people to mis-use then please?

It's not pleasant but if the client gets disconnected I'd assume we
have to just return EIO or something on all outstanding writes and
toss away our dirty data. There's not really another option that makes
any sense, is there?
-Greg

>
> Regards
> Yan, Zheng
>
> > Thanks,
> >
> >                 Ilya



[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