From patchwork Mon Aug 5 11:49:23 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Max Reitz X-Patchwork-Id: 11076583 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 27F3213AC for ; Mon, 5 Aug 2019 11:50:01 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 119C828861 for ; Mon, 5 Aug 2019 11:50:01 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id F35B0287BF; Mon, 5 Aug 2019 11:50:00 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.2 required=2.0 tests=BAYES_00,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED autolearn=ham version=3.3.1 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id 8FE8A287BF for ; Mon, 5 Aug 2019 11:50:00 +0000 (UTC) Received: from localhost ([::1]:52902 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hubV1-0007SB-V9 for patchwork-qemu-devel@patchwork.kernel.org; Mon, 05 Aug 2019 07:49:59 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:37295) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hubUe-0006xg-3G for qemu-devel@nongnu.org; Mon, 05 Aug 2019 07:49:37 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hubUd-0007ep-42 for qemu-devel@nongnu.org; Mon, 05 Aug 2019 07:49:36 -0400 Received: from mx1.redhat.com ([209.132.183.28]:34462) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hubUa-0007cq-Td; Mon, 05 Aug 2019 07:49:33 -0400 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id D14D43083391; Mon, 5 Aug 2019 11:49:31 +0000 (UTC) Received: from localhost (unknown [10.40.205.217]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 5447960610; Mon, 5 Aug 2019 11:49:24 +0000 (UTC) From: Max Reitz To: qemu-block@nongnu.org Date: Mon, 5 Aug 2019 13:49:23 +0200 Message-Id: <20190805114923.23701-1-mreitz@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.44]); Mon, 05 Aug 2019 11:49:31 +0000 (UTC) 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] mirror: Only mirror granularity-aligned chunks 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+patchwork-qemu-devel=patchwork.kernel.org@nongnu.org Sender: "Qemu-devel" X-Virus-Scanned: ClamAV using ClamSMTP In write-blocking mode, all writes to the top node directly go to the target. We must only mirror chunks of data that are aligned to the job's granularity, because that is how the dirty bitmap works. Therefore, the request alignment for writes must be the job's granularity (in write-blocking mode). Unfortunately, this forces all reads and writes to have the same granularity (we only need this alignment for writes to the target, not the source), but that is something to be fixed another time. Signed-off-by: Max Reitz Reviewed-by: Vladimir Sementsov-Ogievskiy --- This is an alternative to Vladimir's "util/hbitmap: fix unaligned reset" patch. I don't mind much either way, both of pros and cons. Comparing this patch to Vladimir's: + Makes copy-mode=write-blocking really work (unless I'm mistaken) - Lowers performance with copy-mode=write-blocking unnecessarily --- block/mirror.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/block/mirror.c b/block/mirror.c index 8cb75fb409..3f9c5a178a 100644 --- a/block/mirror.c +++ b/block/mirror.c @@ -1481,6 +1481,15 @@ static void bdrv_mirror_top_child_perm(BlockDriverState *bs, BdrvChild *c, *nshared = BLK_PERM_ALL; } +static void bdrv_mirror_top_refresh_limits(BlockDriverState *bs, Error **errp) +{ + MirrorBDSOpaque *s = bs->opaque; + + if (s && s->job && s->job->copy_mode == MIRROR_COPY_MODE_WRITE_BLOCKING) { + bs->bl.request_alignment = s->job->granularity; + } +} + /* Dummy node that provides consistent read to its users without requiring it * from its backing file and that allows writes on the backing file chain. */ static BlockDriver bdrv_mirror_top = { @@ -1493,6 +1502,7 @@ static BlockDriver bdrv_mirror_top = { .bdrv_co_block_status = bdrv_co_block_status_from_backing, .bdrv_refresh_filename = bdrv_mirror_top_refresh_filename, .bdrv_child_perm = bdrv_mirror_top_child_perm, + .bdrv_refresh_limits = bdrv_mirror_top_refresh_limits, }; static BlockJob *mirror_start_job( @@ -1678,6 +1688,8 @@ static BlockJob *mirror_start_job( QTAILQ_INIT(&s->ops_in_flight); + bdrv_refresh_limits(mirror_top_bs, &error_abort); + trace_mirror_start(bs, s, opaque); job_start(&s->common.job);