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
next prev parent 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).