From: Eric Blake <eblake@redhat.com>
To: John Snow <jsnow@redhat.com>, qemu-devel@nongnu.org
Cc: Kevin Wolf <kwolf@redhat.com>,
vsementsov@virtuozzo.com,
"open list:Network Block Dev..." <qemu-block@nongnu.org>,
Max Reitz <mreitz@redhat.com>
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 [thread overview]
Message-ID: <5dbb9c0d-4eb0-b6a0-ff23-107010fa3c1f@redhat.com> (raw)
In-Reply-To: <e2c4f996-a1c3-d7aa-fc3e-4fffc596e8de@redhat.com>
[-- Attachment #1.1: Type: text/plain, Size: 2415 bytes --]
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
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2019-08-15 21:55 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-15 18:50 [Qemu-devel] [PATCH] nbd: Advertise multi-conn for shared read-only connections Eric Blake
2019-08-15 20:00 ` Richard W.M. Jones
2019-08-15 21:45 ` [Qemu-devel] [Qemu-block] " John Snow
2019-08-15 21:54 ` Eric Blake [this message]
2019-08-15 22:02 ` John Snow
2019-08-15 22:36 ` [Qemu-devel] " no-reply
2019-08-16 10:23 ` Vladimir Sementsov-Ogievskiy
2019-08-16 10:47 ` Vladimir Sementsov-Ogievskiy
2019-08-17 14:30 ` Eric Blake
2019-08-18 1:31 ` [Qemu-devel] [Qemu-block] " Nir Soffer
2019-08-19 18:04 ` Eric Blake
2019-08-20 21:19 ` Nir Soffer
2019-08-20 9:07 ` [Qemu-devel] " Vladimir Sementsov-Ogievskiy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5dbb9c0d-4eb0-b6a0-ff23-107010fa3c1f@redhat.com \
--to=eblake@redhat.com \
--cc=jsnow@redhat.com \
--cc=kwolf@redhat.com \
--cc=mreitz@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=vsementsov@virtuozzo.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).