All of lore.kernel.org
 help / color / mirror / Atom feed
From: John Snow <jsnow@redhat.com>
To: qemu-block@nongnu.org
Cc: kwolf@redhat.com, famz@redhat.com, jcody@redhat.com,
	qemu-devel@nongnu.org, stefanha@redhat.com,
	John Snow <jsnow@redhat.com>
Subject: [Qemu-devel] [PATCH 2/3] block/backup: avoid copying less than full target clusters
Date: Fri, 12 Feb 2016 18:06:31 -0500	[thread overview]
Message-ID: <1455318392-26765-3-git-send-email-jsnow@redhat.com> (raw)
In-Reply-To: <1455318392-26765-1-git-send-email-jsnow@redhat.com>

During incremental backups, if the target has a cluster size that is
larger than the backup cluster size and we are backing up to a target
that cannot (for whichever reason) pull clusters up from a backing image,
we may inadvertantly create unusable incremental backup images.

For example:

If the bitmap tracks changes at a 64KB granularity and we transmit 64KB
of data at a time but the target uses a 128KB cluster size, it is
possible that only half of a target cluster will be recognized as dirty
by the backup block job. When the cluster is allocated on the target
image but only half populated with data, we lose the ability to
distinguish between zero padding and uninitialized data.

This does not happen if the target image has a backing file that points
to the last known good backup.

Even if we have a backing file, though, it's likely going to be faster
to just buffer the redundant data ourselves from the live image than
fetching it from the backing file, so let's just always round up to the
target granularity.

Signed-off-by: John Snow <jsnow@redhat.com>
---
 block/backup.c | 13 ++++++++++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/block/backup.c b/block/backup.c
index fcf0043..62faf81 100644
--- a/block/backup.c
+++ b/block/backup.c
@@ -568,9 +568,16 @@ void backup_start(BlockDriverState *bs, BlockDriverState *target,
     job->on_target_error = on_target_error;
     job->target = target;
     job->sync_mode = sync_mode;
-    job->sync_bitmap = sync_mode == MIRROR_SYNC_MODE_INCREMENTAL ?
-                       sync_bitmap : NULL;
-    job->cluster_size = BACKUP_CLUSTER_SIZE_DEFAULT;
+    if (sync_mode == MIRROR_SYNC_MODE_INCREMENTAL) {
+        BlockDriverInfo bdi;
+
+        bdrv_get_info(job->target, &bdi);
+        job->sync_bitmap = sync_bitmap;
+        job->cluster_size = MAX(BACKUP_CLUSTER_SIZE_DEFAULT,
+                                bdi.cluster_size);
+    } else {
+        job->cluster_size = BACKUP_CLUSTER_SIZE_DEFAULT;
+    }
     job->sectors_per_cluster = job->cluster_size / BDRV_SECTOR_SIZE;
     job->common.len = len;
     job->common.co = qemu_coroutine_create(backup_run);
-- 
2.4.3

  parent reply	other threads:[~2016-02-12 23:06 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-12 23:06 [Qemu-devel] [PATCH 0/3] blockjob: correct backup cluster size for incremental backups John Snow
2016-02-12 23:06 ` [Qemu-devel] [PATCH 1/3] block/backup: make backup cluster size configurable John Snow
2016-02-14  6:46   ` Fam Zheng
2016-02-16 13:38     ` John Snow
2016-02-12 23:06 ` John Snow [this message]
2016-02-14  6:49   ` [Qemu-devel] [PATCH 2/3] block/backup: avoid copying less than full target clusters Fam Zheng
2016-02-16 15:43     ` John Snow
2016-02-12 23:06 ` [Qemu-devel] [PATCH 3/3] iotests/124: Add cluster_size mismatch test John Snow
2016-02-14  7:08   ` Fam Zheng

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=1455318392-26765-3-git-send-email-jsnow@redhat.com \
    --to=jsnow@redhat.com \
    --cc=famz@redhat.com \
    --cc=jcody@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=qemu-block@nongnu.org \
    --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 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.