From nobody Mon Feb 9 21:20:48 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zoho.com: domain of gnu.org designates 209.51.188.17 as permitted sender) client-ip=209.51.188.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists.gnu.org; Authentication-Results: mx.zohomail.com; spf=pass (zoho.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=fail(p=none dis=none) header.from=redhat.com ARC-Seal: i=1; a=rsa-sha256; t=1564681386; cv=none; d=zoho.com; s=zohoarc; b=P+vTyEz3bw81e6Y/lLCfGrMD8DxmHEKY4zIzt9wC4u3Tf+iiKWqY0BKUDlDUNNF+L2eybDoRmV81BsarFHiNh8MraNUpBTx/EjKOIGDhBFIgDj3wK0GCWShkUwybnIFEbuLQ09iAObz9QQEjghyZ8Pkkpv1zHKzgf06I73RrCqk= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zoho.com; s=zohoarc; t=1564681386; h=Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:To:ARC-Authentication-Results; bh=IFHgjRBRs4fDv0pnp2Xlm9glTYkTTSH1tealj0AfjJg=; b=V7jZupxgPoYmfESIUD+ss+i0AyCUsyCOLAVgB+WQ1jpDy5UjLWDda0/9yZev7g6+6F0fXmH9urTdYLI5xnIvruIXhou72NrR6QphYV5tkaJ/TQVzw005MiZMXzWzq8rmdLRqIWEPpipqxZyYRHg1Z/g9nkTtJjnUb0H6BhHlIUY= ARC-Authentication-Results: i=1; mx.zoho.com; spf=pass (zoho.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=fail header.from= (p=none dis=none) header.from= Return-Path: Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) by mx.zohomail.com with SMTPS id 1564681386892360.0610829697448; Thu, 1 Aug 2019 10:43:06 -0700 (PDT) Received: from localhost ([::1]:57998 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1htF6V-0004HQ-6A for importer@patchew.org; Thu, 01 Aug 2019 13:43:03 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:49426) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1htF3F-0002J4-1C for qemu-devel@nongnu.org; Thu, 01 Aug 2019 13:39:44 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1htF35-0005Mi-NW for qemu-devel@nongnu.org; Thu, 01 Aug 2019 13:39:35 -0400 Received: from mx1.redhat.com ([209.132.183.28]:60722) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1htF2l-0005A4-7t; Thu, 01 Aug 2019 13:39:11 -0400 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id B61468D3B2; Thu, 1 Aug 2019 17:39:09 +0000 (UTC) Received: from localhost (ovpn-204-187.brq.redhat.com [10.40.204.187]) by smtp.corp.redhat.com (Postfix) with ESMTPS id E721F600C6; Thu, 1 Aug 2019 17:39:06 +0000 (UTC) From: Max Reitz To: qemu-block@nongnu.org Date: Thu, 1 Aug 2019 19:38:59 +0200 Message-Id: <20190801173900.23851-2-mreitz@redhat.com> In-Reply-To: <20190801173900.23851-1-mreitz@redhat.com> References: <20190801173900.23851-1-mreitz@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Thu, 01 Aug 2019 17:39:09 +0000 (UTC) Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.132.183.28 Subject: [Qemu-devel] [PATCH v2 for-4.1 1/2] backup: Copy only dirty areas X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Kevin Wolf , Vladimir Sementsov-Ogievskiy , John Snow , qemu-devel@nongnu.org, Max Reitz Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: "Qemu-devel" Content-Type: text/plain; charset="utf-8" The backup job must only copy areas that the copy_bitmap reports as dirty. This is always the case when using traditional non-offloading backup, because it copies each cluster separately. When offloading the copy operation, we sometimes copy more than one cluster at a time, but we only check whether the first one is dirty. Therefore, whenever copy offloading is possible, the backup job currently produces wrong output when the guest writes to an area of which an inner part has already been backed up, because that inner part will be re-copied. Fixes: 9ded4a0114968e98b41494fc035ba14f84cdf700 Signed-off-by: Max Reitz Reviewed-by: Vladimir Sementsov-Ogievskiy --- block/backup.c | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/block/backup.c b/block/backup.c index 715e1d3be8..1ee271f9f1 100644 --- a/block/backup.c +++ b/block/backup.c @@ -202,22 +202,31 @@ static int coroutine_fn backup_do_cow(BackupBlockJob = *job, cow_request_begin(&cow_request, job, start, end); =20 while (start < end) { + int64_t dirty_end; + if (!hbitmap_get(job->copy_bitmap, start)) { trace_backup_do_cow_skip(job, start); start +=3D job->cluster_size; continue; /* already copied */ } =20 + dirty_end =3D hbitmap_next_zero(job->copy_bitmap, start, (end - st= art)); + if (dirty_end < 0) { + dirty_end =3D end; + } + trace_backup_do_cow_process(job, start); =20 if (job->use_copy_range) { - ret =3D backup_cow_with_offload(job, start, end, is_write_noti= fier); + ret =3D backup_cow_with_offload(job, start, dirty_end, + is_write_notifier); if (ret < 0) { job->use_copy_range =3D false; } } if (!job->use_copy_range) { - ret =3D backup_cow_with_bounce_buffer(job, start, end, is_writ= e_notifier, + ret =3D backup_cow_with_bounce_buffer(job, start, dirty_end, + is_write_notifier, error_is_read, &bounce_buf= fer); } if (ret < 0) { --=20 2.21.0