Re: [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