[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [Qemu-block] [PATCH] nbd: Advertise multi-conn for shar
From: |
Nir Soffer |
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 |
On Mon, Aug 19, 2019 at 9:04 PM Eric Blake <address@hidden> 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
>
>
- Re: [Qemu-devel] [PATCH] nbd: Advertise multi-conn for shared read-only connections, (continued)
- Re: [Qemu-devel] [PATCH] nbd: Advertise multi-conn for shared read-only connections, Richard W.M. Jones, 2019/08/15
- Re: [Qemu-devel] [Qemu-block] [PATCH] nbd: Advertise multi-conn for shared read-only connections, John Snow, 2019/08/15
- Re: [Qemu-devel] [PATCH] nbd: Advertise multi-conn for shared read-only connections, no-reply, 2019/08/15
- Re: [Qemu-devel] [PATCH] nbd: Advertise multi-conn for shared read-only connections, Vladimir Sementsov-Ogievskiy, 2019/08/16
- Re: [Qemu-devel] [PATCH] nbd: Advertise multi-conn for shared read-only connections, Vladimir Sementsov-Ogievskiy, 2019/08/20