qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Max Reitz <mreitz@redhat.com>
To: John Snow <jsnow@redhat.com>, qemu-devel@nongnu.org
Cc: kwolf@redhat.com, Fam Zheng <famz@redhat.com>,
	armbru@redhat.com, vsementsov@parallels.com, stefanha@redhat.com,
	pbonzini@redhat.com
Subject: Re: [Qemu-devel] [PATCH v8 07/10] qmp: Add support of "dirty-bitmap" sync mode for drive-backup
Date: Thu, 27 Nov 2014 11:19:13 +0100	[thread overview]
Message-ID: <5476FAA1.2060608@redhat.com> (raw)
In-Reply-To: <1417023715-18210-8-git-send-email-jsnow@redhat.com>

On 2014-11-26 at 18:41, John Snow wrote:
> From: Fam Zheng <famz@redhat.com>
>
> For "dirty-bitmap" sync mode, the block job will iterate through the
> given dirty bitmap to decide if a sector needs backup (backup all the
> dirty clusters and skip clean ones), just as allocation conditions of
> "top" sync mode.
>
> There are two bitmap use modes for sync=dirty-bitmap:
>
>   - reset: backup job makes a copy of bitmap and resets the original
>     one.
>   - consume: backup job makes the original anonymous (invisible to user)
>     and releases it after use.
>
> Signed-off-by: Fam Zheng <famz@redhat.com>
> Signed-off-by: John Snow <jsnow@redhat.com>
> ---
>   block.c                   |   5 ++
>   block/backup.c            | 130 ++++++++++++++++++++++++++++++++++++++--------
>   block/mirror.c            |   4 ++
>   blockdev.c                |  18 ++++++-
>   hmp.c                     |   4 +-
>   include/block/block.h     |   1 +
>   include/block/block_int.h |   6 +++
>   qapi/block-core.json      |  30 +++++++++--
>   qmp-commands.hx           |   7 +--
>   9 files changed, 175 insertions(+), 30 deletions(-)

[snip]

> diff --git a/block/backup.c b/block/backup.c
> index 792e655..2aab68f 100644
> --- a/block/backup.c
> +++ b/block/backup.c
> @@ -386,6 +438,36 @@ void backup_start(BlockDriverState *bs, BlockDriverState *target,
>           return;
>       }
>   
> +    if (sync_mode == MIRROR_SYNC_MODE_DIRTY_BITMAP) {
> +        if (!sync_bitmap) {
> +            error_setg(errp, "must provide a valid bitmap name for "
> +                             "\"dirty-bitmap\" sync mode");
> +            return;
> +        }
> +
> +        switch (bitmap_mode) {
> +        case BITMAP_USE_MODE_RESET:
> +            original = sync_bitmap;
> +            sync_bitmap = bdrv_copy_dirty_bitmap(bs, sync_bitmap, NULL);
> +            bdrv_reset_dirty_bitmap(bs, original);
> +            break;
> +        case BITMAP_USE_MODE_CONSUME:
> +            bdrv_dirty_bitmap_make_anon(bs, sync_bitmap);
> +            break;
> +        default:
> +            error_setg(errp, "Invalid BitmapUseMode (%s) given to backup_start",
> +                       BitmapUseMode_lookup[bitmap_mode]);
> +            return;

Well, this is basically the opposite of what I'd done, but making it 
difficult by formatting a nice error message for the user in places 
which should never be reached instead of just aborting is not wrong, in 
my opinion (I do know that others have other opinions).

[snip]

> diff --git a/blockdev.c b/blockdev.c
> index 276a31b..1a56959 100644
> --- a/blockdev.c
> +++ b/blockdev.c
> @@ -2337,7 +2342,18 @@ void qmp_drive_backup(const char *device, const char *target,
>   
>       bdrv_set_aio_context(target_bs, aio_context);
>   
> -    backup_start(bs, target_bs, speed, sync, on_source_error, on_target_error,
> +    if (has_bitmap) {
> +        bmap = bdrv_find_dirty_bitmap(bs, bitmap);
> +        if (!bmap) {
> +            error_setg(errp, "A bitmap name was given, but bitmap '%s' could not be found",
> +                       bitmap);

Well, I do know I said that I'd translate "has_bitmap was set" to "A 
bitmap name was specified", but I assumed you'd remove the redundancy 
yourself. ;-)

Since this line needs to be reworked anyway (see Fam's reply), it can be 
(imho) shortened to "Bitmap '%s' could not be found". The user should 
know that he/she has specified a bitmap, and that it did have that name; 
the only thing he/she doesn't know so far is that qemu failed to find 
that bitmap, so that's the information we need to give.

With that line somehow shortened/split to 80 characters (I'd be fine 
with keeping its content as-is, I just think it'd sound strange to the 
user):

Reviewed-by: Max Reitz <mreitz@redhat.com>

  parent reply	other threads:[~2014-11-27 10:19 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-26 17:41 [Qemu-devel] [PATCH v8 00/10] block: Incremental backup series John Snow
2014-11-26 17:41 ` [Qemu-devel] [PATCH v8 01/10] qapi: Add optional field "name" to block dirty bitmap John Snow
2014-11-27  9:36   ` Max Reitz
2014-11-26 17:41 ` [Qemu-devel] [PATCH v8 02/10] qmp: Add block-dirty-bitmap-add and block-dirty-bitmap-remove John Snow
2014-11-27  9:41   ` Max Reitz
2014-12-01 18:52     ` John Snow
2014-12-02  9:34       ` Max Reitz
2014-11-26 17:41 ` [Qemu-devel] [PATCH v8 03/10] block: Introduce bdrv_dirty_bitmap_granularity() John Snow
2014-11-27  9:42   ` Max Reitz
2014-11-26 17:41 ` [Qemu-devel] [PATCH v8 04/10] hbitmap: Add hbitmap_copy John Snow
2014-11-27  9:43   ` Max Reitz
2014-11-26 17:41 ` [Qemu-devel] [PATCH v8 05/10] block: Add bdrv_copy_dirty_bitmap and bdrv_reset_dirty_bitmap John Snow
2014-11-27  9:44   ` Max Reitz
2014-11-26 17:41 ` [Qemu-devel] [PATCH v8 06/10] qmp: Add block-dirty-bitmap-enable and block-dirty-bitmap-disable John Snow
2014-11-27 10:03   ` Max Reitz
2014-11-26 17:41 ` [Qemu-devel] [PATCH v8 07/10] qmp: Add support of "dirty-bitmap" sync mode for drive-backup John Snow
2014-11-27  9:18   ` Fam Zheng
2014-11-27 10:19   ` Max Reitz [this message]
2014-11-26 17:41 ` [Qemu-devel] [PATCH v8 08/10] qapi: Add transaction support to block-dirty-bitmap-{add, enable, disable} John Snow
2014-11-27 10:25   ` Max Reitz
2014-11-26 17:41 ` [Qemu-devel] [PATCH v8 09/10] qmp: Add dirty bitmap 'enabled' field in query-block John Snow
2014-11-27 10:26   ` Max Reitz
2014-11-26 17:41 ` [Qemu-devel] [PATCH v8 10/10] qemu-iotests: Add tests for drive-backup sync=dirty-bitmap John Snow
2014-11-27 10:27   ` Max Reitz

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=5476FAA1.2060608@redhat.com \
    --to=mreitz@redhat.com \
    --cc=armbru@redhat.com \
    --cc=famz@redhat.com \
    --cc=jsnow@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.com \
    --cc=vsementsov@parallels.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).