qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Eric Blake <eblake@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: kwolf@redhat.com, jcody@redhat.com, qemu-devel@nongnu.org,
	stefanha@redhat.com
Subject: Re: [Qemu-devel] [PATCH 08/20] mirror: allow customizing the granularity
Date: Fri, 14 Dec 2012 15:01:04 -0700	[thread overview]
Message-ID: <50CBA1A0.7020302@redhat.com> (raw)
In-Reply-To: <1355319999-30627-9-git-send-email-pbonzini@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 4142 bytes --]

On 12/12/2012 06:46 AM, Paolo Bonzini wrote:
> The desired granularity may be very different depending on the kind of
> operation (e.g. continuous replication vs. collapse-to-raw) and whether
> the VM is expected to perform lots of I/O while mirroring is in progress.
> 
> Allow the user to customize it, while providing a sane default so that
> in general there will be no extra allocated space in the target compared
> to the source.

Might be worth mentioning that this configuration still has to be done
prior to starting the job (ie. it's a one-time initialization, not
something that is run-time tweakable).

> 
> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> ---
>  block/mirror.c   | 50 ++++++++++++++++++++++++++++++++------------------
>  block_int.h      |  3 ++-
>  blockdev.c       | 15 ++++++++++++++-
>  hmp.c            |  2 +-
>  qapi-schema.json |  8 +++++++-
>  qmp-commands.hx  |  8 +++++++-
>  6 files changed, 63 insertions(+), 23 deletions(-)

> @@ -330,7 +329,7 @@ static BlockJobType mirror_job_type = {
>  };
>  
>  void mirror_start(BlockDriverState *bs, BlockDriverState *target,
> -                  int64_t speed, MirrorSyncMode mode,
> +                  int64_t speed, int64_t granularity, MirrorSyncMode mode,
>                    BlockdevOnError on_source_error,
>                    BlockdevOnError on_target_error,
>                    BlockDriverCompletionFunc *cb,
> @@ -338,6 +337,20 @@ void mirror_start(BlockDriverState *bs, BlockDriverState *target,
>  {
>      MirrorBlockJob *s;
>  
> +    if (granularity == 0) {
> +        /* Choose the default granularity based on the target file's cluster
> +         * size, clamped between 4k and 64k.  */
> +        BlockDriverInfo bdi;
> +        if (bdrv_get_info(target, &bdi) >= 0 && bdi.cluster_size != 0) {
> +            granularity = MAX(4096, bdi.cluster_size);
> +            granularity = MIN(65536, granularity);

You clamp granularity to sane bounds when defaulting...

> +        } else {
> +            granularity = 65536;
> +        }
> +    }
> +
> +    assert((granularity & (granularity - 1)) == 0);

...but don't do any checking other than power-of-two on user input.  Can
the user request a granularity that makes no sense, such as something
less than 512 or huge like 1G?  Or for that matter, is it even a problem
if the user requests a granularity larger than the target bdi.cluster_size?

> @@ -1217,6 +1218,17 @@ void qmp_drive_mirror(const char *device, const char *target,
>      if (!has_mode) {
>          mode = NEW_IMAGE_MODE_ABSOLUTE_PATHS;
>      }
> +    if (!has_granularity) {
> +        granularity = 0;
> +    }
> +    if (granularity != 0 && (granularity < 512 || granularity > 1048576 * 64)) {

That answers part of my question - you clamp between 512 and 64M, which
is a much wider range than the defaults you end up choosing.

> +++ b/qapi-schema.json
> @@ -1636,6 +1636,11 @@
>  #        (all the disk, only the sectors allocated in the topmost image, or
>  #        only new I/O).
>  #
> +# @granularity: #optional granularity of the dirty bitmap, default is 64K
> +#               if the image format doesn't have clusters, 4K if the clusters
> +#               are smaller than that, else the cluster size.  Must be a
> +#               power of 2 between 512 and 64M.

Maybe mention that this attribute was added in 1.4.  (Hmm, now I have to
decide how to expose this attribute via libvirt.)

> @@ -971,6 +973,10 @@ Arguments:
>  - "on-target-error": the action to take on an error on the target
>    (BlockdevOnError, default 'report')
>  
> +The default value of the granularity is, if the image format defines
> +a cluster size, the cluster size or 4096, whichever is larger.  If it
> +does not define a cluster size, the default value of the granularity
> +is 65536.

That doesn't quite cover the fact that you clamp granularity to 64k if
the image format has a cluster size larger than 64k.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 619 bytes --]

  reply	other threads:[~2012-12-14 22:01 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-12-12 13:46 [Qemu-devel] [PATCH 00/20] Block device mirroring enhancements, 12-12-12 edition Paolo Bonzini
2012-12-12 13:46 ` [Qemu-devel] [PATCH 01/20] host-utils: add ffsl Paolo Bonzini
2012-12-12 23:41   ` Eric Blake
2012-12-12 13:46 ` [Qemu-devel] [PATCH 02/20] add hierarchical bitmap data type and test cases Paolo Bonzini
2012-12-14  0:04   ` Eric Blake
2013-01-11 18:27   ` Stefan Hajnoczi
2012-12-12 13:46 ` [Qemu-devel] [PATCH 03/20] block: implement dirty bitmap using HBitmap Paolo Bonzini
2012-12-14  0:27   ` Eric Blake
2012-12-12 13:46 ` [Qemu-devel] [PATCH 04/20] block: make round_to_clusters public Paolo Bonzini
2012-12-14 20:13   ` Eric Blake
2012-12-12 13:46 ` [Qemu-devel] [PATCH 05/20] mirror: perform COW if the cluster size is bigger than the granularity Paolo Bonzini
2012-12-14 20:21   ` Eric Blake
2012-12-12 13:46 ` [Qemu-devel] [PATCH 06/20] block: return count of dirty sectors, not chunks Paolo Bonzini
2012-12-14 20:49   ` Eric Blake
2012-12-12 13:46 ` [Qemu-devel] [PATCH 07/20] block: allow customizing the granularity of the dirty bitmap Paolo Bonzini
2012-12-14 21:27   ` Eric Blake
2012-12-15  9:11     ` Paolo Bonzini
2012-12-12 13:46 ` [Qemu-devel] [PATCH 08/20] mirror: allow customizing the granularity Paolo Bonzini
2012-12-14 22:01   ` Eric Blake [this message]
2013-01-14 11:28   ` Stefan Hajnoczi
2012-12-12 13:46 ` [Qemu-devel] [PATCH 09/20] mirror: switch mirror_iteration to AIO Paolo Bonzini
2012-12-14 22:11   ` Eric Blake
2012-12-15  9:09     ` Paolo Bonzini
2012-12-15 13:05       ` Eric Blake
2012-12-12 13:46 ` [Qemu-devel] [PATCH 10/20] mirror: add buf-size argument to drive-mirror Paolo Bonzini
2012-12-14 22:22   ` Eric Blake
2012-12-15  9:09     ` Paolo Bonzini
2013-01-14 11:41   ` Stefan Hajnoczi
2012-12-12 13:46 ` [Qemu-devel] [PATCH 11/20] mirror: support more than one in-flight AIO operation Paolo Bonzini
2012-12-14 22:32   ` Eric Blake
2013-01-14 12:56   ` Stefan Hajnoczi
2013-01-14 13:28     ` Paolo Bonzini
2012-12-12 13:46 ` [Qemu-devel] [PATCH 12/20] mirror: support arbitrarily-sized iterations Paolo Bonzini
2012-12-14 22:39   ` Eric Blake
2012-12-12 13:46 ` [Qemu-devel] [PATCH 13/20] oslib: add a wrapper for mmap/munmap Paolo Bonzini
2012-12-14 22:54   ` Eric Blake
2012-12-15  9:06     ` Paolo Bonzini
2012-12-12 13:46 ` [Qemu-devel] [PATCH 14/20] hbitmap: add hbitmap_alloc_with_data and hbitmap_required_size Paolo Bonzini
2012-12-17 17:14   ` Eric Blake
2012-12-17 17:18     ` Paolo Bonzini
2012-12-12 13:46 ` [Qemu-devel] [PATCH 15/20] hbitmap: add hbitmap_copy Paolo Bonzini
2012-12-17 18:25   ` Eric Blake
2012-12-12 13:46 ` [Qemu-devel] [PATCH 16/20] block: split bdrv_enable_dirty_tracking and bdrv_disable_dirty_tracking Paolo Bonzini
2012-12-20 18:26   ` Eric Blake
2012-12-12 13:46 ` [Qemu-devel] [PATCH 17/20] block: support a persistent dirty bitmap Paolo Bonzini
2012-12-20 23:03   ` Eric Blake
2012-12-12 13:46 ` [Qemu-devel] [PATCH 18/20] mirror: add support for " Paolo Bonzini
2012-12-20 23:49   ` Eric Blake
2012-12-12 13:46 ` [Qemu-devel] [PATCH 19/20] block: choose the default dirty bitmap granularity in bdrv_enable_dirty_tracking Paolo Bonzini
2012-12-20 23:53   ` Eric Blake
2012-12-12 13:46 ` [Qemu-devel] [PATCH 20/20] monitor: add commands to start/stop dirty bitmap Paolo Bonzini
2012-12-21 18:30   ` Eric Blake
2013-01-14 13:02 ` [Qemu-devel] [PATCH 00/20] Block device mirroring enhancements, 12-12-12 edition Stefan Hajnoczi

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=50CBA1A0.7020302@redhat.com \
    --to=eblake@redhat.com \
    --cc=jcody@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.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).