From: "Richard W.M. Jones" <rjones@redhat.com>
To: Markus Armbruster <armbru@redhat.com>
Cc: kwolf@redhat.com, vsementsov@virtuozzo.com,
qemu-block@nongnu.org, qemu-devel@nongnu.org,
Max Reitz <mreitz@redhat.com>,
stefanha@redhat.com
Subject: Re: [PATCH v3 2/6] nbd: Add 'qemu-nbd -A' to expose allocation depth
Date: Fri, 9 Oct 2020 10:03:38 +0100 [thread overview]
Message-ID: <20201009090338.GE30079@redhat.com> (raw)
In-Reply-To: <87lfgfom51.fsf@dusky.pond.sub.org>
On Fri, Oct 09, 2020 at 10:10:18AM +0200, Markus Armbruster wrote:
> Eric Blake <eblake@redhat.com> writes:
>
> > Allow the server to expose an additional metacontext to be requested
> > by savvy clients. qemu-nbd adds a new option -A to expose the
> > qemu:allocation-depth metacontext through NBD_CMD_BLOCK_STATUS; this
> > can also be set via QMP when using block-export-add.
> >
> > qemu as client can be hacked into viewing this new context by using
> > the now-misnamed x-dirty-bitmap option when creating an NBD blockdev
> > (even though our x- naming means we could rename it, I did not think
> > it worth breaking back-compat of tools that have been using it while
> > waiting for a better solution). It is worth noting the decoding of
> > how such context information will appear in 'qemu-img map
> > --output=json':
> >
> > NBD_STATE_DEPTH_UNALLOC => "zero":false, "data":true
> > NBD_STATE_DEPTH_LOCAL => "zero":false, "data":false
> > NBD_STATE_DEPTH_BACKING => "zero":true, "data":true
> >
> > libnbd as client is probably a nicer way to get at the information
> > without having to decipher such hacks in qemu as client. ;)
> >
> > Signed-off-by: Eric Blake <eblake@redhat.com>
> > Message-Id: <20200930121105.667049-6-eblake@redhat.com>
> > Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
> > [eblake: comment tweak suggested by Vladimir]
> > Signed-off-by: Eric Blake <eblake@redhat.com>
> > ---
> [...]
> > diff --git a/qapi/block-core.json b/qapi/block-core.json
> > index 3758ea991269..249bd434f4eb 100644
> > --- a/qapi/block-core.json
> > +++ b/qapi/block-core.json
> > @@ -3882,9 +3882,12 @@
> > #
> > # @tls-creds: TLS credentials ID
> > #
> > -# @x-dirty-bitmap: A "qemu:dirty-bitmap:NAME" string to query in place of
> > +# @x-dirty-bitmap: A metacontext name such as "qemu:dirty-bitmap:NAME" or
>
> What is a "metacontext"?
>
> Aside: nbd.h spells it "meta context". The two spellings suggest
> different meanings to me. Using meta- as a prefix modifies the prefixed
> word, as in metadata (data that provides information about other data).
> Separated by space, meta becomes a noun. None of its common meanings
> seem to apply here. Recommend to pick an appropriate one of
> "metacontext", "meta-context", "meta context", and stick to it.
In the NBD protocol it's called a "metadata context". This is
abbreviated to "...META_CONTEXT" in the names of constants,
eg. NBD_OPT_SET_META_CONTEXT. For the reasons you gave I don't think
it's a very good name, but it's what we have.
https://github.com/NetworkBlockDevice/nbd/blob/master/doc/proto.md#metadata-querying
What it actually is, is a string, like "base:allocation" or
"qemu:dirty-bitmap:<NAME>" which selects which metadata you want to
query in NBD_CMD_BLOCK_STATUS commands.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine. Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
next prev parent reply other threads:[~2020-10-09 9:04 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-09 2:07 [PATCH v3 0/6] Exposing backing-chain allocation over NBD Eric Blake
2020-10-09 2:07 ` [PATCH v3 1/6] nbd: Add new qemu:allocation-depth metacontext Eric Blake
2020-10-09 2:07 ` [PATCH v3 2/6] nbd: Add 'qemu-nbd -A' to expose allocation depth Eric Blake
2020-10-09 8:10 ` Markus Armbruster
2020-10-09 9:03 ` Richard W.M. Jones [this message]
2020-10-09 12:13 ` Eric Blake
2020-10-09 2:07 ` [PATCH v3 3/6] nbd: Update qapi to support multiple bitmaps Eric Blake
2020-10-09 2:07 ` [PATCH v3 4/6] nbd: Simplify qemu bitmap context name Eric Blake
2020-10-09 2:07 ` [PATCH v3 5/6] nbd: Refactor counting of meta contexts Eric Blake
2020-10-09 2:07 ` [PATCH v3 6/6] nbd: Allow export of multiple bitmaps for one device Eric Blake
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=20201009090338.GE30079@redhat.com \
--to=rjones@redhat.com \
--cc=armbru@redhat.com \
--cc=kwolf@redhat.com \
--cc=mreitz@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.