qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Eric Blake <eblake@redhat.com>
To: "Richard W.M. Jones" <rjones@redhat.com>
Cc: Kevin Wolf <kwolf@redhat.com>,
	Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>,
	qemu-block@nongnu.org, qemu-devel@nongnu.org,
	Markus Armbruster <armbru@redhat.com>,
	nsoffer@redhat.com, Hanna Reitz <hreitz@redhat.com>,
	v.sementsov-og@ya.ru
Subject: Re: [PATCH v3 3/3] nbd/server: Allow MULTI_CONN for shared writable exports
Date: Wed, 16 Mar 2022 16:15:53 -0500	[thread overview]
Message-ID: <20220316211553.5t5vujgu4rh7zpew@redhat.com> (raw)
In-Reply-To: <20220316210718.yt3xcaqlg2sduyje@redhat.com>

On Wed, Mar 16, 2022 at 04:07:21PM -0500, Eric Blake wrote:
> On Tue, Mar 15, 2022 at 01:14:41PM +0000, Richard W.M. Jones wrote:
> > The patches seem OK to me, but I don't really know enough about the
> > internals of qemu-nbd to give a line-by-line review.  I did however
> > build and test qemu-nbd with the patches:
> > 
> >   $ ./build/qemu-nbd /var/tmp/test.qcow2 
> >   $ nbdinfo nbd://localhost
> >   ...
> > 	can_multi_conn: false
> > 
> > 
> >   $ ./build/qemu-nbd -e 2 /var/tmp/test.qcow2 
> >   $ nbdinfo nbd://localhost
> >   ...
> > 	can_multi_conn: false
> > 
> > ^^^ Is this expected?  It also happens with -e 0.
> 
> Yes, because qemu-nbd defaults to read-write connections, but to be
> conservative, this patch defaults '-m auto' to NOT advertise
> multi-conn for read-write; you need to be explicit:
> 
> > 
> > 
> >   $ ./build/qemu-nbd -e 2 -m on /var/tmp/test.qcow2 
> >   $ nbdinfo nbd://localhost
> >   ...
> > 	can_multi_conn: true
> 
> either with '-m on' as you did here, or with
> 
> build/qemu-nbd -r -e 2 /var/tmp/test.qcow2
> 
> where the '-m auto' default exposes multi-conn for a readonly client.

I hit send prematurely - one more thought I wanted to make clear.  For
_this_ series, the behavior of '-m auto' depends solely on readonly
vs. read-write; that being the most conservative choice of preserving
pre-existing qemu-nbd behavior (that is, if you don't use -m, the only
change in behavior should be the fact that --help output now lists
-m).

But in future versions of qemu, we might be able to improve '-m auto'
to also take into consideration whether the backing image of a
read-write device is known-cache-consistent (such as a local file
system), where we can then manage to default to advertising multi-conn
for those writable images, while still avoiding the advertisement when
exposing other devices such as network-mounted devices where we are
less confident on whether there are sufficient cache consistency
guarantees.  Use of explicit '-m off' or '-m on' gives guaranteed
results no matter the qemu version, so it is only explicit (or
implied) '-m auto' where we might get smarter defaults over time.

Thus testing whether advertising multi-conn makes a difference in
other tools like nbdcopy thus requires checking if qemu-nbd is new
enough to support -m, and then being explicit that we are opting in to
using it.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org



  reply	other threads:[~2022-03-16 21:16 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-14 20:38 [PATCH v3 0/3] nbd: MULTI_CONN for shared writable exports Eric Blake
2022-03-14 20:38 ` [PATCH v3 1/3] docs: Consistent typography for options of qemu-nbd Eric Blake
2022-03-17  8:15   ` Daniel P. Berrangé
2022-03-14 20:38 ` [PATCH v3 2/3] qemu-nbd: Pass max connections to blockdev layer Eric Blake
2022-03-14 20:38 ` [PATCH v3 3/3] nbd/server: Allow MULTI_CONN for shared writable exports Eric Blake
2022-03-15 13:14   ` Richard W.M. Jones
2022-03-16 21:07     ` Eric Blake
2022-03-16 21:15       ` Eric Blake [this message]
2022-03-16 23:01         ` Richard W.M. Jones
2022-04-27 15:52   ` Kevin Wolf
2022-04-27 21:39     ` Eric Blake
2022-04-29 12:49       ` Kevin Wolf
2022-05-02 21:12         ` Eric Blake
2022-05-03  7:56           ` Kevin Wolf
2022-04-22 20:23 ` [PATCH v3 0/3] nbd: " Eric Blake

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=20220316211553.5t5vujgu4rh7zpew@redhat.com \
    --to=eblake@redhat.com \
    --cc=armbru@redhat.com \
    --cc=hreitz@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=nsoffer@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=rjones@redhat.com \
    --cc=v.sementsov-og@ya.ru \
    --cc=vsementsov@virtuozzo.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).