From: Eric Blake <eblake@redhat.com>
To: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>,
qemu-devel@nongnu.org, qemu-block@nongnu.org
Cc: armbru@redhat.com, mreitz@redhat.com, kwolf@redhat.com,
pbonzini@redhat.com, den@openvz.org
Subject: Re: [Qemu-devel] [PATCH 3/4] nbd/server: implement dirty bitmap export
Date: Wed, 21 Mar 2018 11:57:57 -0500 [thread overview]
Message-ID: <e21af76d-977d-cadf-0a27-14a2d2aa228a@redhat.com> (raw)
In-Reply-To: <20180321121940.39426-4-vsementsov@virtuozzo.com>
On 03/21/2018 07:19 AM, Vladimir Sementsov-Ogievskiy wrote:
> Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Rather sparse on the details in the commit message; I had to read the
patch to even learn what the new namespace is.
> ---
> include/block/nbd.h | 2 +
> nbd/server.c | 207 ++++++++++++++++++++++++++++++++++++++++++++++++++--
> 2 files changed, 203 insertions(+), 6 deletions(-)
>
> +++ b/nbd/server.c
> @@ -23,6 +23,12 @@
> #include "nbd-internal.h"
>
> #define NBD_META_ID_BASE_ALLOCATION 0
> +#define NBD_META_ID_DIRTY_BITMAP 1
> +
> +#define NBD_MAX_BITMAP_EXTENTS (0x100000 / 8) /* 1 mb of extents data */
> +#define MAX_EXTENT_LENGTH QEMU_ALIGN_DOWN(INT32_MAX, 512)
Worth comments on these two limits?
> +
> +#define NBD_STATE_DIRTY 1
Does this belong better in nbd.h, alongside NBD_STATE_HOLE? (And
defining it as (1 << 0) might be nicer, too).
>
> static int system_errno_to_nbd_errno(int err)
> {
> @@ -80,6 +86,9 @@ struct NBDExport {
>
> BlockBackend *eject_notifier_blk;
> Notifier eject_notifier;
> +
> + BdrvDirtyBitmap *export_bitmap;
> + char *export_bitmap_name;
> };
>
> static QTAILQ_HEAD(, NBDExport) exports = QTAILQ_HEAD_INITIALIZER(exports);
> @@ -92,6 +101,7 @@ typedef struct NBDExportMetaContexts {
> bool valid; /* means that negotiation of the option finished without
> errors */
> bool base_allocation; /* export base:allocation context (block status) */
> + bool dirty_bitmap; /* export qemu-dirty-bitmap:<export_bitmap_name> */
That's a LONG namespace name, and it does not lend itself well to other
qemu extensions; so future qemu BLOCK_STATUS additions would require
consuming yet another namespace and additional upstream NBD
registration. Wouldn't it be better to have the namespace be 'qemu:'
(which we register with upstream NBD just once), where we are then free
to document leafnames to look like 'dirty-bitmap:name' or 'foo:bar'?
> } NBDExportMetaContexts;
>
> struct NBDClient {
> @@ -786,12 +796,32 @@ static int nbd_meta_base_query(NBDClient *client, NBDExportMetaContexts *meta,
> &meta->base_allocation, errp);
> }
>
> +/* nbd_meta_bitmap_query
> + *
> + * Handle query to 'qemu-dirty-bitmap' namespace.
> + * 'len' is the amount of text remaining to be read from the current name, after
> + * the 'qemu-dirty-bitmap:' portion has been stripped.
> + *
> + * Return -errno on I/O error, 0 if option was completely handled by
> + * sending a reply about inconsistent lengths, or 1 on success. */
> +static int nbd_meta_bitmap_query(NBDClient *client, NBDExportMetaContexts *meta,
> + uint32_t len, Error **errp)
> +{
> + if (!client->exp->export_bitmap) {
> + return nbd_opt_skip(client, len, errp);
> + }
> +
> + return nbd_meta_single_query(client, client->exp->export_bitmap_name, len,
> + &meta->dirty_bitmap, errp);
So if I'm reading this right, a client can do _LIST_
'qemu-dirty-bitmap:' (or 'qemu:dirty-bitmap:' if we choose a shorter
initial namespace) and get back the exported bitmap name; or the user
already knows the bitmap name and both _LIST_ and _SET_
'qemu-dirty-bitmap:name' return the one supported bitmap for that NBD
server.
> /* nbd_co_send_extents
> + *
> + * NBD_REPLY_FLAG_DONE is not set, don't forget to send it.
> + *
> * @extents should be in big-endian */
> static int nbd_co_send_extents(NBDClient *client, uint64_t handle,
> NBDExtent *extents, unsigned nb_extents,
Worth a bool flag that the caller can inform this function whether to
include FLAG_DONE?
> +
> +static int nbd_co_send_bitmap(NBDClient *client, uint64_t handle,
> + BdrvDirtyBitmap *bitmap, uint64_t offset,
> + uint64_t length, uint32_t context_id,
> + Error **errp)
> +{
> + int ret;
> + unsigned nb_extents;
> + NBDExtent *extents = g_new(NBDExtent, NBD_MAX_BITMAP_EXTENTS);
Is this correct even when the client used NBD_CMD_FLAG_REQ_ONE?
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
next prev parent reply other threads:[~2018-03-21 16:58 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-21 12:19 [Qemu-devel] [PATCH for-2.13 0/4] NBD export bitmaps Vladimir Sementsov-Ogievskiy
2018-03-21 12:19 ` [Qemu-devel] [PATCH 1/4] nbd/server: refactor nbd_negotiate_meta_query for several namespaces Vladimir Sementsov-Ogievskiy
2018-03-21 14:56 ` Eric Blake
2018-03-21 17:20 ` Wouter Verhelst
2018-03-22 14:35 ` Vladimir Sementsov-Ogievskiy
2018-03-21 12:19 ` [Qemu-devel] [PATCH 2/4] nbd/server: add nbd_meta_single_query helper Vladimir Sementsov-Ogievskiy
2018-03-21 15:05 ` Eric Blake
2018-04-13 17:44 ` Vladimir Sementsov-Ogievskiy
2018-04-13 21:06 ` [Qemu-devel] [Qemu-block] " John Snow
2018-04-16 11:22 ` Vladimir Sementsov-Ogievskiy
2018-03-21 12:19 ` [Qemu-devel] [PATCH 3/4] nbd/server: implement dirty bitmap export Vladimir Sementsov-Ogievskiy
2018-03-21 16:57 ` Eric Blake [this message]
2018-03-22 15:26 ` Vladimir Sementsov-Ogievskiy
2018-03-28 10:08 ` Vladimir Sementsov-Ogievskiy
2018-03-22 15:32 ` Vladimir Sementsov-Ogievskiy
2018-03-21 12:19 ` [Qemu-devel] [PATCH 4/4] qapi: new qmp command nbd-server-add-bitmap Vladimir Sementsov-Ogievskiy
2018-03-21 17:33 ` Eric Blake
2018-03-22 15:43 ` Vladimir Sementsov-Ogievskiy
2018-03-22 16:19 ` Eric Blake
2018-03-22 16:45 ` 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=e21af76d-977d-cadf-0a27-14a2d2aa228a@redhat.com \
--to=eblake@redhat.com \
--cc=armbru@redhat.com \
--cc=den@openvz.org \
--cc=kwolf@redhat.com \
--cc=mreitz@redhat.com \
--cc=pbonzini@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).