From: Eric Blake <eblake@redhat.com>
To: qemu-devel@nongnu.org
Cc: Stefan Hajnoczi <stefanha@redhat.com>,
John Snow <jsnow@redhat.com>,
Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>,
Kevin Wolf <kwolf@redhat.com>, Hanna Reitz <hreitz@redhat.com>,
qemu-block@nongnu.org (open list:Block Jobs)
Subject: [PULL 14/14] mirror: Reduce I/O when destination is detect-zeroes:unmap
Date: Wed, 14 May 2025 21:28:57 -0500 [thread overview]
Message-ID: <20250515022904.575509-30-eblake@redhat.com> (raw)
In-Reply-To: <20250515022904.575509-16-eblake@redhat.com>
If we are going to punch holes in the mirror destination even for the
portions where the source image is unallocated, it is nicer to treat
the entire image as dirty and punch as we go, rather than pre-zeroing
the entire image just to re-do I/O to the allocated portions of the
image.
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-ID: <20250513220142.535200-2-eblake@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
---
block/mirror.c | 13 +++++++++----
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/block/mirror.c b/block/mirror.c
index 724318f0371..c2c5099c951 100644
--- a/block/mirror.c
+++ b/block/mirror.c
@@ -920,11 +920,16 @@ static int coroutine_fn GRAPH_UNLOCKED mirror_dirty_init(MirrorBlockJob *s)
* zeroing happened externally (ret > 0) or if we have a fast
* way to pre-zero the image (the dirty bitmap will be
* populated later by the non-zero portions, the same as for
- * TOP mode). If pre-zeroing is not fast, then our only
- * recourse is to mark the entire image dirty. The act of
- * pre-zeroing will populate the zero bitmap.
+ * TOP mode). If pre-zeroing is not fast, or we need to visit
+ * the entire image in order to punch holes even in the
+ * non-allocated regions of the source, then just mark the
+ * entire image dirty and leave the zero bitmap clear at this
+ * point in time. Otherwise, it can be faster to pre-zero the
+ * image now, even if we re-write the allocated portions of
+ * the disk later, and the pre-zero pass will populate the
+ * zero bitmap.
*/
- if (!bdrv_can_write_zeroes_with_unmap(target_bs)) {
+ if (!bdrv_can_write_zeroes_with_unmap(target_bs) || punch_holes) {
bdrv_set_dirty_bitmap(s->dirty_bitmap, 0, s->bdev_length);
return 0;
}
--
2.49.0
next prev parent reply other threads:[~2025-05-15 2:31 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-15 2:28 [PULL 00/14] NBD patches for 2025-05-14 Eric Blake
2025-05-15 2:28 ` [PULL 01/14] block: Expand block status mode from bool to flags Eric Blake
2025-05-15 2:28 ` [PULL 02/14] file-posix, gluster: Handle zero block status hint better Eric Blake
2025-05-15 2:28 ` [PULL 03/14] block: Let bdrv_co_is_zero_fast consolidate adjacent extents Eric Blake
2025-05-15 2:28 ` [PULL 04/14] block: Add new bdrv_co_is_all_zeroes() function Eric Blake
2025-05-15 2:28 ` [PULL 05/14] iotests: Improve iotest 194 to mirror data Eric Blake
2025-05-15 2:28 ` [PULL 06/14] mirror: Minor refactoring Eric Blake
2025-05-15 2:28 ` [PULL 07/14] mirror: Pass full sync mode rather than bool to internals Eric Blake
2025-05-15 2:28 ` [PULL 08/14] mirror: Allow QMP override to declare target already zero Eric Blake
2025-05-15 2:28 ` [PULL 09/14] mirror: Drop redundant zero_target parameter Eric Blake
2025-05-15 2:28 ` [PULL 10/14] mirror: Skip pre-zeroing destination if it is already zero Eric Blake
2025-05-15 2:28 ` [PULL 11/14] mirror: Skip writing zeroes when target " Eric Blake
2025-05-15 2:28 ` [PULL 12/14] iotests/common.rc: add disk_usage function Eric Blake
2025-05-15 2:28 ` [PULL 13/14] tests: Add iotest mirror-sparse for recent patches Eric Blake
2025-05-21 9:54 ` Fiona Ebner
2025-05-21 15:32 ` Eric Blake
2025-05-22 7:30 ` Fiona Ebner
2025-05-28 11:39 ` Markus Armbruster
2025-05-28 12:40 ` Eric Blake
2025-05-28 13:27 ` Markus Armbruster
2025-05-28 15:40 ` Eric Blake
2025-05-28 16:23 ` Markus Armbruster
2025-05-28 18:22 ` Eric Blake
2025-05-15 2:28 ` Eric Blake [this message]
2025-05-15 21:53 ` [PULL 00/14] NBD patches for 2025-05-14 Stefan Hajnoczi
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=20250515022904.575509-30-eblake@redhat.com \
--to=eblake@redhat.com \
--cc=hreitz@redhat.com \
--cc=jsnow@redhat.com \
--cc=kwolf@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@redhat.com \
--cc=vsementsov@yandex-team.ru \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).