Re: [Qemu-devel] [Qemu-block] [PATCH] nbd: Advertise multi-conn for shared read-only connections

[Nir Soffer]

On Sat, Aug 17, 2019 at 5:30 PM Eric Blake <address@hidden> wrote:

> On 8/16/19 5:47 AM, Vladimir Sementsov-Ogievskiy wrote:
>
> >>> +++ b/blockdev-nbd.c
> >>> @@ -189,7 +189,7 @@ void qmp_nbd_server_add(const char *device, bool
> has_name, const char *name,
> >>>       }
> >>>
> >>>       exp = nbd_export_new(bs, 0, len, name, NULL, bitmap,
> >>> -                         writable ? 0 : NBD_FLAG_READ_ONLY,
> >>> +                         writable ? 0 : NBD_FLAG_READ_ONLY, true,
> >>
> >> s/true/!writable ?
> >
> > Oh, I see, John already noticed this, it's checked in nbd_export_new
> anyway..
>
> Still, since two reviewers have caught it, I'm fixing it :)
>
>
> >>> @@ -1486,6 +1486,8 @@ NBDExport *nbd_export_new(BlockDriverState *bs,
> uint64_t dev_offset,
> >>>       perm = BLK_PERM_CONSISTENT_READ;
> >>>       if ((nbdflags & NBD_FLAG_READ_ONLY) == 0) {
> >>>           perm |= BLK_PERM_WRITE;
> >>> +    } else if (shared) {
> >>> +        nbdflags |= NBD_FLAG_CAN_MULTI_CONN;
> >
> > For me it looks a bit strange: we already have nbdflags parameter for
> nbd_export_new(), why
> > to add a separate boolean to pass one of nbdflags flags?
>
> Because I want to get rid of the nbdflags in my next patch.
>
> >
> > 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.

Do we have real issue in qemu-nbd serving multiple clients writing to
different parts of
the same image?

Nir