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
next prev 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).