[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Nir Soffer
Subject: Re: [Qemu-block] [PATCH] nbd: Advertise multi-conn for shared read-only connections
Date: Sun, 18 Aug 2019 04:31:53 +0300

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?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]