From: Eric Blake <eblake@redhat.com>
To: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>,
qemu-devel@nongnu.org
Cc: kwolf@redhat.com, Max Reitz <mreitz@redhat.com>,
stefanha@redhat.com, qemu-block@nongnu.org, rjones@redhat.com
Subject: Re: [PATCH v5 11/12] nbd: Expose actual depth in qemu:allocation-depth
Date: Mon, 26 Oct 2020 07:31:24 -0500 [thread overview]
Message-ID: <f3652fe4-4233-3ecc-ed1d-c23046d26396@redhat.com> (raw)
In-Reply-To: <909e397b-ebee-7380-717c-7800c32195ce@virtuozzo.com>
On 10/24/20 4:59 AM, Vladimir Sementsov-Ogievskiy wrote:
> 23.10.2020 21:36, Eric Blake wrote:
>> Preserve the tri-state encoding in the low bits, as that still remains
>> a valuable way to utilize qemu-img map with x-dirty-bitmap for
>> accessing quick information without needing a third-party NBD client.
>
> Hmm.. that doesn't sound as a good reason for redundant information in
> the protocol. Previously good reason was additional effort needed to
> implement sever part, but you've implemented it. And if we export depth
> anyway, it seems better to hack a bit nbd_client_co_block_status to
> convert extent.flags appropriately if metadata context is
> "qemu:allocation-depth" (to keep x-dirty-bitmap working), than have a
> workaround at the protocol layer.
I'm happy to respin this to expose JUST a depth rather than redundant
information, but time is short if we want it in 5.2 (as soft freeze is
this week). I'll see what I can get to today; I'll rearrange the series
to put multiple bitmap exports first (as that appears ready), while
saving 'qemu-nbd -A' until we're happy with the qemu:allocation-depth
semantics. After all, once we release something, we've committed to
that user interface.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org
next prev parent reply other threads:[~2020-10-26 12:36 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-23 18:36 [PATCH v5 00/12] Exposing backing-chain allocation over NBD Eric Blake
2020-10-23 18:36 ` [PATCH v5 01/12] qapi: Move GenericList to qapi/util.h Eric Blake
2020-10-24 9:06 ` Vladimir Sementsov-Ogievskiy
2020-10-26 14:18 ` Markus Armbruster
2020-10-26 14:22 ` Eric Blake
2020-10-23 18:36 ` [PATCH v5 02/12] qapi: Make QAPI_LIST_ADD() public Eric Blake
2020-10-24 9:10 ` Vladimir Sementsov-Ogievskiy
2020-10-26 14:25 ` Markus Armbruster
2020-10-26 14:37 ` Eric Blake
2020-10-26 14:38 ` Eric Blake
2020-10-23 18:36 ` [PATCH v5 03/12] nbd: Utilize QAPI_CLONE for type conversion Eric Blake
2020-10-24 9:17 ` Vladimir Sementsov-Ogievskiy
2020-10-26 14:41 ` Markus Armbruster
2020-10-23 18:36 ` [PATCH v5 04/12] nbd: Add new qemu:allocation-depth metadata context Eric Blake
2020-10-23 18:36 ` [PATCH v5 05/12] nbd: Add 'qemu-nbd -A' to expose allocation depth Eric Blake
2020-10-23 18:36 ` [PATCH v5 06/12] nbd: Update qapi to support exporting multiple bitmaps Eric Blake
2020-10-26 10:50 ` Peter Krempa
2020-10-26 13:06 ` Eric Blake
2020-10-23 18:36 ` [PATCH v5 07/12] nbd: Simplify qemu bitmap context name Eric Blake
2020-10-23 18:36 ` [PATCH v5 08/12] nbd: Refactor counting of metadata contexts Eric Blake
2020-10-23 18:36 ` [PATCH v5 09/12] nbd: Allow export of multiple bitmaps for one device Eric Blake
2020-10-23 18:36 ` [PATCH v5 10/12] block: Return depth level during bdrv_is_allocated_above Eric Blake
2020-10-24 9:49 ` Vladimir Sementsov-Ogievskiy
2020-10-26 12:26 ` Vladimir Sementsov-Ogievskiy
2020-10-23 18:36 ` [PATCH v5 11/12] nbd: Expose actual depth in qemu:allocation-depth Eric Blake
2020-10-24 9:59 ` Vladimir Sementsov-Ogievskiy
2020-10-26 12:31 ` Eric Blake [this message]
2020-10-23 18:36 ` [PATCH v5 12/12] qapi: Use QAPI_LIST_ADD() where possible Eric Blake
2020-10-23 20:23 ` Eric Blake
2020-10-23 18:44 ` [PATCH v5 00/12] Exposing backing-chain allocation over NBD Eric Blake
2020-10-26 14:54 ` Markus Armbruster
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=f3652fe4-4233-3ecc-ed1d-c23046d26396@redhat.com \
--to=eblake@redhat.com \
--cc=kwolf@redhat.com \
--cc=mreitz@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=rjones@redhat.com \
--cc=stefanha@redhat.com \
--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).