From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 8C063CE8D6B for ; Mon, 17 Nov 2025 17:36:37 +0000 (UTC) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1vL38s-0001bb-Ka; Mon, 17 Nov 2025 12:35:54 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1vL38k-0001WO-5u for qemu-devel@nongnu.org; Mon, 17 Nov 2025 12:35:47 -0500 Received: from us-smtp-delivery-124.mimecast.com ([170.10.129.124]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1vL38h-00039Y-1r for qemu-devel@nongnu.org; Mon, 17 Nov 2025 12:35:45 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1763400939; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Yp+RWM1jxOk3yjbwcfonU/tf8SaoDD9Cbi6t+0nmuIo=; b=NoeyM4a3LP5Lfya4fPFBDsgqUkxeY0o6V+VztzK1mFb15+Sg2Iu5FiGBtvK8RQsamU2PNt Zby65/To0xtXYbhVh7gYgGAoIx2VHeBFOyZVLDpl0gO/mcP8YgNFNBseE40/rdQfRNXZj2 dXD+bW7KGJvnZnMLLyIa68PVgNlVoFg= Received: from mx-prod-mc-08.mail-002.prod.us-west-2.aws.redhat.com (ec2-35-165-154-97.us-west-2.compute.amazonaws.com [35.165.154.97]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-21-foo5yZ65OUa5f2bmxCWJBg-1; Mon, 17 Nov 2025 12:35:37 -0500 X-MC-Unique: foo5yZ65OUa5f2bmxCWJBg-1 X-Mimecast-MFC-AGG-ID: foo5yZ65OUa5f2bmxCWJBg_1763400936 Received: from mx-prod-int-05.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-05.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.17]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id EFD1B1800597; Mon, 17 Nov 2025 17:35:35 +0000 (UTC) Received: from redhat.com (unknown [10.44.33.115]) by mx-prod-int-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 73842195608E; Mon, 17 Nov 2025 17:35:33 +0000 (UTC) Date: Mon, 17 Nov 2025 18:35:30 +0100 From: Kevin Wolf To: Eric Blake Cc: luzhipeng , qemu-block@nongnu.org, John Snow , Hanna Reitz , qemu-devel@nongnu.org Subject: Re: [PATCH] mirror: Optimize mirroring for zero blocks in mirror_read_complete Message-ID: References: <20250922113657.391-1-luzhipeng@cestc.cn> <20250922113657.391-2-luzhipeng@cestc.cn> <2pfcwex4mzczvrezsv5mmlnd5elfgg2yt5akymfe7dslksnlbr@yyjlkqoibnpb> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2pfcwex4mzczvrezsv5mmlnd5elfgg2yt5akymfe7dslksnlbr@yyjlkqoibnpb> X-Scanned-By: MIMEDefang 3.0 on 10.30.177.17 Received-SPF: pass client-ip=170.10.129.124; envelope-from=kwolf@redhat.com; helo=us-smtp-delivery-124.mimecast.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=unavailable autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Am 22.09.2025 um 14:53 hat Eric Blake geschrieben: > Then a higher-level question. Should we teach blk_co_pwritev() to > have a flag that ANY caller can set to request write-zero > optimizations, rather than having to open-code a check and call to > blk_co_pwrite_zeroes() at every call-site that might benefit? > > Optimizing to a write zero is often nice, but using BDRV_REQ_MAY_UNMAP > may break use cases that have explicitly requested full allocation. > The more we can consolidate all of the decisions about whether or not > to use write zeroes, and whether or not to allow unmap in that > attempt, into a single common function rather than duplicated out at > every call site that might benefit, the easier it will be to maintain > the code down the road. > > Thus, I'm wondering if it might be better to introduce a new BDRV_REQ_ > flag for passing to blk_co_pwritev for deciding to trigger potential > write-zero optimizations. We already have the detect-zeroes=on|off|unmap option, which is used in bdrv_aligned_pwritev() to enable this kind of optimisation. I think we should reuse this code in some way. We also should configure the mirror job in a similar way, adding a new detect-zeroes=on|off|unmap option to blockdev-mirror (and off will stay the default). One option is, as you say, that we introduce BDRV_REQ_* flags that could take effect even when the BlockDriverState isn't configured to detect zeroes. For a three-way option, we'd need a combination of two flags, though, or a two-bit field. I'm not sure how much I like this. The other option is that you just set detect-zeroes on the target node that mirror points to. What makes this a bit harder is that mirror only owns the BlockBackend, but no node on the target side (on the source side, we have the mirror_top filter), and suddenly inserting new nodes isn't great either. So this is probably something that mirror can't do for you, but you as the user would have to configure the target node explicitly this way. Kevin