All of lore.kernel.org
 help / color / mirror / Atom feed
From: Josef Bacik <jbacik@fb.com>
To: Wouter Verhelst <w@uter.be>
Cc: <axboe@kernel.dk>, <nbd-general@lists.sourceforge.net>,
	<linux-block@vger.kernel.org>, <kernel-team@fb.com>
Subject: Re: [Nbd] [PATCH 6/6] nbd: add a basic netlink interface
Date: Wed, 8 Mar 2017 09:56:48 -0500	[thread overview]
Message-ID: <1488985008.9307.29.camel@fb.com> (raw)
In-Reply-To: <20170308100704.xdxuhlpsttigfreq@grep.be>

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 ;).  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.  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.  Thanks,

Josef

  reply	other threads:[~2017-03-08 14:56 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-28 16:57 [PATCH 0/6] Lots of NBD fixes and enhancements Josef Bacik
2017-02-28 16:57 ` [PATCH 1/6] nbd: handle single path failures gracefully Josef Bacik
2017-02-28 16:57 ` [PATCH 2/6] nbd: ref count the nbd device Josef Bacik
2017-02-28 16:57 ` [PATCH 3/6] nbd: stop using the bdev everywhere Josef Bacik
2017-02-28 16:57 ` [PATCH 4/6] nbd: set queue timeout properly Josef Bacik
2017-02-28 16:57 ` [PATCH 5/6] nbd: handle ERESTARTSYS properly Josef Bacik
2017-02-28 16:57 ` [PATCH 6/6] nbd: add a basic netlink interface Josef Bacik
2017-03-08 10:07   ` [Nbd] " Wouter Verhelst
2017-03-08 14:56     ` Josef Bacik [this message]
2017-03-08 20:44       ` Wouter Verhelst

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1488985008.9307.29.camel@fb.com \
    --to=jbacik@fb.com \
    --cc=axboe@kernel.dk \
    --cc=kernel-team@fb.com \
    --cc=linux-block@vger.kernel.org \
    --cc=nbd-general@lists.sourceforge.net \
    --cc=w@uter.be \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.