qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Kevin Wolf <kwolf@redhat.com>
To: John Snow <jsnow@redhat.com>
Cc: pkrempa@redhat.com, Eduardo Habkost <ehabkost@redhat.com>,
	qemu-block@nongnu.org, qemu-devel@nongnu.org,
	Markus Armbruster <armbru@redhat.com>,
	vsementsov@virtuozzo.com, Cleber Rosa <crosa@redhat.com>,
	Max Reitz <mreitz@redhat.com>
Subject: Re: [PATCH RFC v2 1/5] block: add bitmap-populate job
Date: Thu, 4 Jun 2020 11:01:40 +0200	[thread overview]
Message-ID: <20200604090140.GB4512@linux.fritz.box> (raw)
In-Reply-To: <20200514034922.24834-2-jsnow@redhat.com>

Am 14.05.2020 um 05:49 hat John Snow geschrieben:
> This job copies the allocation map into a bitmap. It's a job because
> there's no guarantee that allocation interrogation will be quick (or
> won't hang), so it cannot be retrofit into block-dirty-bitmap-merge.
> 
> It was designed with different possible population patterns in mind,
> but only top layer allocation was implemented for now.
> 
> Signed-off-by: John Snow <jsnow@redhat.com>
> ---
>  qapi/block-core.json      |  48 +++++++++
>  qapi/job.json             |   2 +-
>  include/block/block_int.h |  21 ++++
>  block/bitmap-alloc.c      | 207 ++++++++++++++++++++++++++++++++++++++

bitmap-populate.c to be more consistent with the actual job name?

>  blockjob.c                |   3 +-
>  block/Makefile.objs       |   1 +
>  6 files changed, 280 insertions(+), 2 deletions(-)
>  create mode 100644 block/bitmap-alloc.c

[...]

> +BlockJob *bitpop_job_create(
> +    const char *job_id,
> +    BlockDriverState *bs,
> +    BdrvDirtyBitmap *target_bitmap,
> +    BitmapPattern pattern,
> +    BlockdevOnError on_error,
> +    int creation_flags,
> +    BlockCompletionFunc *cb,
> +    void *opaque,
> +    JobTxn *txn,
> +    Error **errp)
> +{
> +    int64_t len;
> +    BitpopBlockJob *job = NULL;
> +    int64_t cluster_size;
> +    BdrvDirtyBitmap *new_bitmap = NULL;
> +
> +    assert(bs);
> +    assert(target_bitmap);
> +
> +    if (!bdrv_is_inserted(bs)) {
> +        error_setg(errp, "Device is not inserted: %s",
> +                   bdrv_get_device_name(bs));
> +        return NULL;
> +    }
> +
> +    if (bdrv_op_is_blocked(bs, BLOCK_OP_TYPE_BACKUP_SOURCE, errp)) {
> +        return NULL;
> +    }

What does this protect? And why does BACKUP_SOURCE describe acccurately
what this job does?

> +    if (bdrv_dirty_bitmap_check(target_bitmap, BDRV_BITMAP_DEFAULT, errp)) {
> +        return NULL;
> +    }
> +
> +    if (pattern != BITMAP_PATTERN_ALLOCATION_TOP) {
> +        error_setg(errp, "Unrecognized bitmap pattern");
> +        return NULL;
> +    }
> +
> +    len = bdrv_getlength(bs);
> +    if (len < 0) {
> +        error_setg_errno(errp, -len, "unable to get length for '%s'",
> +                         bdrv_get_device_name(bs));

This operates on the node level, so bdrv_get_device_or_node_name() is
necessary to avoid empty strings in the message.

> +        return NULL;
> +    }
> +
> +    /* NB: new bitmap is anonymous and enabled */
> +    cluster_size = bdrv_dirty_bitmap_granularity(target_bitmap);
> +    new_bitmap = bdrv_create_dirty_bitmap(bs, cluster_size, NULL, errp);
> +    if (!new_bitmap) {
> +        return NULL;
> +    }
> +
> +    /* Take ownership; we reserve the right to write into this on-commit. */
> +    bdrv_dirty_bitmap_set_busy(target_bitmap, true);
> +
> +    job = block_job_create(job_id, &bitpop_job_driver, txn, bs,
> +                           BLK_PERM_CONSISTENT_READ,

I don't think we actually rely on CONSISTENT_READ, but then, using the
job on inconsistent nodes probably makes little sense and we can always
relax the restriction later if necessary.

> +                           BLK_PERM_ALL & ~BLK_PERM_RESIZE,
> +                           0, creation_flags,
> +                           cb, opaque, errp);
> +    if (!job) {
> +        bdrv_dirty_bitmap_set_busy(target_bitmap, false);
> +        bdrv_release_dirty_bitmap(new_bitmap);
> +        return NULL;
> +    }
> +
> +    job->bs = bs;
> +    job->on_error = on_error;
> +    job->target_bitmap = target_bitmap;
> +    job->new_bitmap = new_bitmap;
> +    job->len = len;
> +    job_progress_set_remaining(&job->common.job, job->len);
> +
> +    return &job->common;
> +}

Kevin



  parent reply	other threads:[~2020-06-04  9:02 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-14  3:49 [PATCH RFC v2 0/5] block: add block-dirty-bitmap-populate job John Snow
2020-05-14  3:49 ` [PATCH RFC v2 1/5] block: add bitmap-populate job John Snow
2020-05-18 20:49   ` Eric Blake
2020-05-19  8:27     ` Peter Krempa
2020-06-04  9:12     ` Kevin Wolf
2020-06-04  9:16       ` Peter Krempa
2020-06-04 11:31         ` Kevin Wolf
2020-06-04 16:22           ` Peter Krempa
2020-06-05  9:01             ` Kevin Wolf
2020-06-05  9:24               ` Peter Krempa
2020-06-05  9:44                 ` Kevin Wolf
2020-06-05  9:58                   ` Peter Krempa
2020-06-05 10:07                     ` Kevin Wolf
2020-06-05 10:59                       ` Peter Krempa
2020-06-06  6:55                         ` Vladimir Sementsov-Ogievskiy
2020-06-08  9:21                           ` Kevin Wolf
2020-06-08 10:00                             ` Vladimir Sementsov-Ogievskiy
2020-06-08 13:15                               ` Kevin Wolf
2020-06-08  9:38                           ` Peter Krempa
2020-06-08 10:30                             ` Vladimir Sementsov-Ogievskiy
2020-06-08 12:01                               ` Peter Krempa
2020-06-04  9:01   ` Kevin Wolf [this message]
2020-06-16 19:46     ` Eric Blake
2020-06-16 19:51       ` John Snow
2020-06-16 20:02       ` Eric Blake
2020-06-17 10:57         ` Kevin Wolf
2020-05-14  3:49 ` [PATCH RFC v2 2/5] blockdev: combine DriveBackupState and BlockdevBackupState John Snow
2020-05-18 20:57   ` Eric Blake
2020-05-14  3:49 ` [PATCH RFC v2 3/5] qmp: expose block-dirty-bitmap-populate John Snow
2020-05-18 21:10   ` Eric Blake
2020-05-14  3:49 ` [PATCH RFC v2 4/5] iotests: move bitmap helpers into their own file John Snow
2020-05-14  3:49 ` [PATCH RFC v2 5/5] iotests: add 287 for block-dirty-bitmap-populate John Snow
2020-05-18 21:22   ` Eric Blake
2020-06-04  9:24   ` Kevin Wolf
2020-05-18 14:52 ` [PATCH RFC v2 0/5] block: add block-dirty-bitmap-populate job Peter Krempa
2020-06-09 15:04   ` Peter Krempa
2020-06-05 21:51 ` 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=20200604090140.GB4512@linux.fritz.box \
    --to=kwolf@redhat.com \
    --cc=armbru@redhat.com \
    --cc=crosa@redhat.com \
    --cc=ehabkost@redhat.com \
    --cc=jsnow@redhat.com \
    --cc=mreitz@redhat.com \
    --cc=pkrempa@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).