From: Nir Soffer <nsoffer@redhat.com>
To: Eric Blake <eblake@redhat.com>
Cc: Kevin Wolf <kwolf@redhat.com>, Daniel Erez <derez@redhat.com>,
Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>,
"open list:Network Block Dev..." <qemu-block@nongnu.org>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
Max Reitz <mreitz@redhat.com>
Subject: Re: [Qemu-devel] [Qemu-block] [PATCH] nbd: Advertise multi-conn for shared read-only connections
Date: Wed, 21 Aug 2019 00:19:27 +0300 [thread overview]
Message-ID: <CAMRbyyv272b83sx8m=kt740+6Pz6c0baUU=xKRNq_Eud1maZbw@mail.gmail.com> (raw)
In-Reply-To: <847b1ef7-0f9d-fd7a-3c0c-368f5d862ecb@redhat.com>
On Mon, Aug 19, 2019 at 9:04 PM Eric Blake <eblake@redhat.com> wrote:
> On 8/17/19 8:31 PM, Nir Soffer wrote:
> >>> Also, for qemu-nbd, shouldn't we allow -e only together with -r ?
> >>
> >> I'm reluctant to; it might break whatever existing user is okay exposing
> >> it (although such users are questionable, so maybe we can argue they
> >> were already broken). Maybe it's time to start a deprecation cycle?
> >>
> >
> > man qemu-nbd (on Centos 7.6) says:
> >
> > -e, --shared=num
> > Allow up to num clients to share the device (default 1)
> >
> > I see that in qemu-img 4.1 there is a note about consistency with
> writers:
> >
> > -e, --shared=num
> > Allow up to num clients to share the device (default 1). Safe
> > for readers, but for now, consistency is not guaranteed between multiple
> > writers.
> > But it is not clear what are the consistency guarantees.
> >
> > Supporting multiple writers is important. oVirt is giving the user a URL
> > (since 4.3), and the user
> > can use multiple connections using the same URL, each having a connection
> > to the same qemu-nbd
> > socket. I know that some backup vendors tried to use multiple connections
> > to speed up backups, and
> > they may try to do this also for restore.
> >
> > An interesting use case would be using multiple connections on client
> side
> > to write in parallel to
> > same image, when every client is writing different ranges.
>
> Good to know.
>
> >
> > Do we have real issue in qemu-nbd serving multiple clients writing to
> > different parts of
> > the same image?
>
> If a server advertises multi-conn on a writable image, then clients have
> stronger guarantees about behavior on what happens with flush on one
> client vs. write in another, to the point that you can make some better
> assumptions about image consistency, including what one client will read
> after another has written. But as long as multiple clients only ever
> access distinct portions of the disk, then multi-conn is not important
> to that client (whether for reading or for writing).
>
Thanks for making this clear. I think we need to document this in oVirt,
so users will be careful about using multiple connections.
>
> So it sounds like I have no reason to deprecate qemu-nbd -e 2, even for
> writable images.
>
> --
> Eric Blake, Principal Software Engineer
> Red Hat, Inc. +1-919-301-3226
> Virtualization: qemu.org | libvirt.org
>
>
next prev parent reply other threads:[~2019-08-20 21:38 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-15 18:50 [Qemu-devel] [PATCH] nbd: Advertise multi-conn for shared read-only connections Eric Blake
2019-08-15 20:00 ` Richard W.M. Jones
2019-08-15 21:45 ` [Qemu-devel] [Qemu-block] " John Snow
2019-08-15 21:54 ` Eric Blake
2019-08-15 22:02 ` John Snow
2019-08-15 22:36 ` [Qemu-devel] " no-reply
2019-08-16 10:23 ` Vladimir Sementsov-Ogievskiy
2019-08-16 10:47 ` Vladimir Sementsov-Ogievskiy
2019-08-17 14:30 ` Eric Blake
2019-08-18 1:31 ` [Qemu-devel] [Qemu-block] " Nir Soffer
2019-08-19 18:04 ` Eric Blake
2019-08-20 21:19 ` Nir Soffer [this message]
2019-08-20 9:07 ` [Qemu-devel] " Vladimir Sementsov-Ogievskiy
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='CAMRbyyv272b83sx8m=kt740+6Pz6c0baUU=xKRNq_Eud1maZbw@mail.gmail.com' \
--to=nsoffer@redhat.com \
--cc=derez@redhat.com \
--cc=eblake@redhat.com \
--cc=kwolf@redhat.com \
--cc=mreitz@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--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).