Re: [Nbd] [PATCH 6/6] nbd: add a basic netlink interface
- To: Josef Bacik <jbacik@...2204...>
- Cc: axboe@...161..., nbd-general@lists.sourceforge.net, kernel-team@...2204..., linux-block@...25...
- Subject: Re: [Nbd] [PATCH 6/6] nbd: add a basic netlink interface
- From: Wouter Verhelst <w@...112...>
- Date: Wed, 8 Mar 2017 21:44:41 +0100
- Message-id: <20170308204441.ywvrsoyrk2qpyji7@...3...>
- In-reply-to: <1488985008.9307.29.camel@...2204...>
- References: <1488301031-3199-1-git-send-email-jbacik@...2204...> <1488301031-3199-7-git-send-email-jbacik@...2204...> <20170308100704.xdxuhlpsttigfreq@...3...> <1488985008.9307.29.camel@...2204...>
On Wed, Mar 08, 2017 at 09:56:48AM -0500, Josef Bacik wrote:
> On Wed, 2017-03-08 at 11:07 +0100, Wouter Verhelst wrote:
> > On Tue, Feb 28, 2017 at 11:57:11AM -0500, Josef Bacik wrote:
> > >
> > > The existing ioctl interface for configuring NBD devices is a bit
> > > cumbersome and hard to extend. The other problem is we leave a
> > > userspace app sitting in it's syscall until the device disconnects,
> > > which is less than ideal.
> > True.
> >
> > On the other hand, it has the advantage that you leave a userspace
> > app
> > sitting around until the device disconnects, which allows for some
> > form
> > of recovery in case you're doing root-on-NBD and the server has a
> > hiccup. Don't underestimate the advantage of that.
> >
> > (of course, that requires that the return value of NBD_DO_IT makes a
> > difference between "unexpected connection drop" and "we sent
> > NBD_CMD_DISC", but that's a different matter entirely)
>
> Stay tuned for further developments ;).
Heh.
> Yeah the problem is that even
> though we can return and allow the user to reconnect, we completely
> tear down the device and will return EIO to anything that comes in
> while we're reconnecting, which sucks for users.
Quite, yes.
> The patches that I'm testing now will multi-cast messages over netlink
> when a link goes down so a user space application can reconnect and
> provide a new connection seamlessly. The next step after that is to
> allow a complete failure of all connections and we will simply sit
> there and queue IO until userspace reconnects or the configured
> timeout elapses at which point we'll tear down the device. The end
> goal of all of this is seamless reconnects without throwing errors.
Awesome. That would mean userspace would need to sit around, but I
suppose that isn't something we can't live with (and actually has other
advantages, too).
Thanks,
--
< ron> I mean, the main *practical* problem with C++, is there's like a dozen
people in the world who think they really understand all of its rules,
and pretty much all of them are just lying to themselves too.
-- #debian-devel, OFTC, 2016-02-12
Reply to: