From: Eric Blake <eblake@redhat.com>
To: qemu-devel@nongnu.org
Cc: nsoffer@redhat.com, vsementsov@virtuozzo.com,
qemu-block@nongnu.org, libguestfs@redhat.com
Subject: [RFC PATCH 0/2] New NBD metacontext
Date: Wed, 9 Jun 2021 13:01:16 -0500 [thread overview]
Message-ID: <20210609180118.1003774-1-eblake@redhat.com> (raw)
This is my counter-proposal to Nir's request [1] to revert a 6.0
behavior change. It does not expose any new information over NBD, but
does make it easier to collect necessary information from a single
context rather than requiring the client to have to request two
contexts in parallel, then cross-correlate what may be different
extent lengths between those contexts. Furthermore, this is easy to
backport to downstream based on qemu 6.0, at which point clients could
use the existence or absence of qemu:joint-allocation as a witness of
whether it can get away with trusting base:allocation when trying to
recreate a qcow2 backing chain.
[1] https://lists.gnu.org/archive/html/qemu-devel/2021-06/msg01796.html
Things I still want to do:
- a followup patch to libnbd to teach 'nbdinfo
--map=qemu:joint-allocation' to decode the bits
- teach 'nbdinfo --map' to read all available contexts, instead of
having to manually type each map besides base:allocation
- potential followup patches to qemu to automatically feed this
information through qemu-img map:
- add a new BDRV_BLOCK_BACKING bit for bdrv_block_status(), with
opposite semantics from BDRV_BLOCK_ALLOCATED, but where the only
thing known is that the data is not local (not how deep it is)
- teach qemu to favor qemu:joint-allocation over base:allocation
when available, and use it to drive BDRV_BLOCK_BACKING
- teach qemu-img map to recognize BDRV_BLOCK_BACKING
Eric Blake (2):
iotests: Improve and rename test 309 to nbd-qemu-allocation
nbd: Add new qemu:joint-allocation metadata context
docs/interop/nbd.txt | 31 ++++++-
docs/tools/qemu-nbd.rst | 4 +-
qapi/block-export.json | 4 +-
include/block/nbd.h | 10 ++-
nbd/server.c | 87 +++++++++++++++++--
.../{309 => tests/nbd-qemu-allocation} | 5 +-
.../nbd-qemu-allocation.out} | 13 ++-
7 files changed, 139 insertions(+), 15 deletions(-)
rename tests/qemu-iotests/{309 => tests/nbd-qemu-allocation} (95%)
rename tests/qemu-iotests/{309.out => tests/nbd-qemu-allocation.out} (79%)
--
2.31.1
next reply other threads:[~2021-06-09 18:03 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-09 18:01 Eric Blake [this message]
2021-06-09 18:01 ` [PATCH 1/2] iotests: Improve and rename test 309 to nbd-qemu-allocation Eric Blake
2021-06-10 12:14 ` Vladimir Sementsov-Ogievskiy
2021-06-09 18:01 ` [PATCH 2/2] nbd: Add new qemu:joint-allocation metadata context Eric Blake
2021-06-09 23:52 ` Nir Soffer
2021-06-10 12:30 ` Vladimir Sementsov-Ogievskiy
2021-06-10 13:47 ` Eric Blake
2021-06-10 14:10 ` Vladimir Sementsov-Ogievskiy
2021-06-10 13:16 ` Nir Soffer
2021-06-10 14:04 ` Eric Blake
2021-06-10 14:43 ` Vladimir Sementsov-Ogievskiy
2021-06-10 13:31 ` Eric Blake
2021-06-11 23:39 ` Nir Soffer
2021-06-14 13:56 ` Eric Blake
2021-06-14 14:06 ` Nir Soffer
2021-06-09 21:31 ` [RFC libnbd PATCH] info: Add support for new qemu:joint-allocation Eric Blake
2021-06-09 22:20 ` Nir Soffer
2021-06-10 13:06 ` Eric Blake
2021-06-10 13:19 ` Nir Soffer
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=20210609180118.1003774-1-eblake@redhat.com \
--to=eblake@redhat.com \
--cc=libguestfs@redhat.com \
--cc=nsoffer@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 read-only IMAP folder(s) and NNTP newsgroup(s).