From patchwork Fri Feb 12 23:06:31 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: John Snow X-Patchwork-Id: 8298441 Return-Path: X-Original-To: patchwork-qemu-devel@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 48D999F1C5 for ; Fri, 12 Feb 2016 23:08:23 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id A42F020435 for ; Fri, 12 Feb 2016 23:08:22 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [208.118.235.17]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id DFA3120434 for ; Fri, 12 Feb 2016 23:08:21 +0000 (UTC) Received: from localhost ([::1]:37114 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aUMp3-00071j-8A for patchwork-qemu-devel@patchwork.kernel.org; Fri, 12 Feb 2016 18:08:21 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49300) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aUMnR-0004Ph-1B for qemu-devel@nongnu.org; Fri, 12 Feb 2016 18:06:42 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aUMnQ-0006KZ-3e for qemu-devel@nongnu.org; Fri, 12 Feb 2016 18:06:40 -0500 Received: from mx1.redhat.com ([209.132.183.28]:49639) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aUMnN-0006Ii-DS; Fri, 12 Feb 2016 18:06:37 -0500 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id 1D61EC0C237F; Fri, 12 Feb 2016 23:06:37 +0000 (UTC) Received: from scv.usersys.redhat.com (dhcp-17-163.bos.redhat.com [10.18.17.163]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u1CN6Yaj018630; Fri, 12 Feb 2016 18:06:36 -0500 From: John Snow To: qemu-block@nongnu.org Date: Fri, 12 Feb 2016 18:06:31 -0500 Message-Id: <1455318392-26765-3-git-send-email-jsnow@redhat.com> In-Reply-To: <1455318392-26765-1-git-send-email-jsnow@redhat.com> References: <1455318392-26765-1-git-send-email-jsnow@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 209.132.183.28 Cc: kwolf@redhat.com, famz@redhat.com, jcody@redhat.com, qemu-devel@nongnu.org, stefanha@redhat.com, John Snow Subject: [Qemu-devel] [PATCH 2/3] block/backup: avoid copying less than full target clusters X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+patchwork-qemu-devel=patchwork.kernel.org@nongnu.org Sender: qemu-devel-bounces+patchwork-qemu-devel=patchwork.kernel.org@nongnu.org X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP 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 --- 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);