[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: |
Eric Blake |
Subject: |
Re: [Qemu-devel] [Qemu-block] [PATCH] nbd: Advertise multi-conn for shared read-only connections |
Date: |
Thu, 15 Aug 2019 16:54:13 -0500 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 |
On 8/15/19 4:45 PM, John Snow wrote:
>
>
> On 8/15/19 2:50 PM, Eric Blake wrote:
>> The NBD specification defines NBD_FLAG_CAN_MULTI_CONN, which can be
>> advertised when the server promises cache consistency between
>> simultaneous clients (basically, rules that determine what FUA and
>> flush from one client are able to guarantee for reads from another
>> client). When we don't permit simultaneous clients (such as qemu-nbd
>> without -e), the bit makes no sense; and for writable images, we
>> probably have a lot more work before we can declare that actions from
>> one client are cache-consistent with actions from another. But for
>> read-only images, where flush isn't changing any data, we might as
>> well advertise multi-conn support. What's more, advertisement of the
>> bit makes it easier for clients to determine if 'qemu-nbd -e' was in
>> use, where a second connection will succeed rather than hang until the
>> first client goes away.
>>
>> This patch affects qemu as server in advertising the bit. We may want
>> to consider patches to qemu as client to attempt parallel connections
>> for higher throughput by spreading the load over those connections
>> when a server advertises multi-conn, but for now sticking to one
>> connection per nbd:// BDS is okay.
>>
>> +++ 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,
>> NULL, false, on_eject_blk, errp);
>
> Why is it okay to force the share bit on regardless of the value of
> 'writable' ?
Well, it's probably not, except that...
>> @@ -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;
>> }
requesting shared=true has no effect for a writable export.
I can tweak it for less confusion, though.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org
signature.asc
Description: OpenPGP digital signature
- [Qemu-devel] [PATCH] nbd: Advertise multi-conn for shared read-only connections, Eric Blake, 2019/08/15
- 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] [Qemu-block] [PATCH] nbd: Advertise multi-conn for shared read-only connections,
Eric Blake <=
- 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