All of lore.kernel.org
 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 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.