From: Andrey Drobyshev <andrey.drobyshev@virtuozzo.com>
To: "Denis V. Lunev" <den@openvz.org>, svt-core@virtuozzo.com
Cc: den@virtuozzo.com
Subject: Re: [PATCH hci-8.0 0/9] block: cheaper zero handling in backup and commit #VSTOR-134085
Date: Wed, 30 Sep 2026 15:49:52 +0300 [thread overview]
Message-ID: <8e3e6894-0f95-4dfd-ab9c-bad9f2f5dc5d@virtuozzo.com> (raw)
In-Reply-To: <20260930111739.3866427-1-den@openvz.org>
No real findings from Sashiko
Ack, applied to hci-dev
Andrey
On 9/30/26 2:17 PM, Denis V. Lunev wrote:
> Backup and commit re-query the source block status for every task and
> size a task by the copy buffer, so a long run of zeroes turns into a
> crowd of small write-zeroes requests. This series reuses what the
> up-front scan already learned and lets one write-zeroes task cover a
> whole run.
>
> This is the series posted upstream as v3, all nine patches with
> Andrey's Reviewed-by:
> https://lore.kernel.org/qemu-devel/20260929155125.3151111-1-den@openvz.org/
>
> hci-8.0 carries 6b1a4754713 ("backup: skip copying unallocated for full
> mode"): sync=full runs the same up-front scan as sync=top, drops the
> clusters the source never allocated, and keeps skip_unallocated set
> afterwards, taking the block-status base from a separate top_mode flag.
> So the upstream cover letter case, a mostly unallocated image, is
> already cheap here. What the series buys on hci-8.0 is allocated zero
> clusters, the ones a guest write-zeroes or detect-zeroes leaves behind,
> in sync=full and in sync=bitmap, and the commit job.
>
> Where the port differs from upstream, 4/9, 7/9, 8/9 and 9/9 say so in
> an "hci-8.0:" paragraph:
> - 3/9: only a context conflict. hci-8.0 lacks upstream a6c131217d,
> which adds coroutine_fn to commit_iteration(), so the signature stays
> as it is here.
> - 4/9: iotest 124 expects a sync=full target to keep the source's
> holes, since the unallocated clusters are skipped rather than written
> as zeroes.
> - 7/9: block_copy_status_base() keys on top_mode instead of
> skip_unallocated, and the scan uses it too instead of computing the
> base on its own.
> - 8/9: sync=full stays on block_copy_reset_unallocated(); only
> sync=bitmap moves to block_copy_calculate_zero_bitmap().
> - 9/9: 6b1a4754713 also made the 056 copy-before-write source read as
> zeroes. One widened write-zeroes task now covers all of it before
> speed=1 can hold the job, so the test caps the task with x-perf
> max-chunk. Andrey, the 4/9 and 9/9 test changes are new with this
> port and not covered by your upstream review.
>
> Every patch builds on its own. On dev007 with qcow2, iotests 040 055 056
> 124 129 141 185 219 257 image-fleecing backup-discard-source
> copy-before-write commit-zero-blocks iothreads-commit-active and
> migrate-during-backup pass. vz-kernel-cbt fails there with and without
> the series, the host kernel has no vz CBT.
>
> On the same host, a 16G qcow2 source holding 1G of data, raw target on
> ext4, counting block_copy_process and commit_one_iteration trace events:
>
> before after
> sync=full, 15G unallocated 1024 0.44s 1024 0.44s
> sync=full, 15G zero clusters 16384 0.66s 1032 0.46s
> sync=bitmap, all dirty, same 16384 0.65s 1032 0.46s
> commit, 15G zero clusters 32768 2.84s 2288 2.70s
>
> Commit time is dominated by copying the 1G of data.
>
> Denis V. Lunev (9):
> block/commit: pass BDRV_WANT_PRECISE to block-status #VSTOR-134085
> iotests/040: cover large and fragmented commit runs #VSTOR-134085
> block/commit: batch block-status queries #VSTOR-134085
> iotests/124: cover backup of zero clusters and holes #VSTOR-134085
> block/block-copy: don't reserve memory for zero tasks #VSTOR-134085
> block/block-copy: extract block_copy_set_task_method() #VSTOR-134085
> block/block-copy: track known-zero source clusters #VSTOR-134085
> block/backup: pre-fill zero_bitmap for full/bitmap #VSTOR-134085
> block/block-copy: coalesce write-zeroes tasks #VSTOR-134085
>
> block/backup.c | 94 ++++++----
> block/block-copy.c | 309 +++++++++++++++++++++++++++-----
> block/commit.c | 59 +++++--
> include/block/block-copy.h | 5 +
> tests/qemu-iotests/040 | 102 ++++++++++-
> tests/qemu-iotests/040.out | 4 +-
> tests/qemu-iotests/056 | 3 +-
> tests/qemu-iotests/124 | 350 ++++++++++++++++++++++++++++++++++++-
> tests/qemu-iotests/124.out | 4 +-
> 9 files changed, 830 insertions(+), 100 deletions(-)
>
>
> base-commit: f2f4b3de1a1be3360a77ca6ab79762466d238804
prev parent reply other threads:[~2026-09-30 12:49 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-30 11:17 Denis V. Lunev
2026-09-30 11:17 ` [PATCH hci-8.0 1/9] block/commit: pass BDRV_WANT_PRECISE to block-status #VSTOR-134085 Denis V. Lunev
2026-09-30 11:20 ` no-reply
2026-09-30 11:17 ` [PATCH hci-8.0 2/9] iotests/040: cover large and fragmented commit runs #VSTOR-134085 Denis V. Lunev
2026-09-30 11:19 ` no-reply
2026-09-30 11:17 ` [PATCH hci-8.0 3/9] block/commit: batch block-status queries #VSTOR-134085 Denis V. Lunev
2026-09-30 11:21 ` no-reply
2026-09-30 11:17 ` [PATCH hci-8.0 4/9] iotests/124: cover backup of zero clusters and holes #VSTOR-134085 Denis V. Lunev
2026-09-30 11:31 ` no-reply
2026-09-30 11:17 ` [PATCH hci-8.0 5/9] block/block-copy: don't reserve memory for zero tasks #VSTOR-134085 Denis V. Lunev
2026-09-30 11:22 ` no-reply
2026-09-30 11:17 ` [PATCH hci-8.0 6/9] block/block-copy: extract block_copy_set_task_method() #VSTOR-134085 Denis V. Lunev
2026-09-30 11:22 ` no-reply
2026-09-30 11:17 ` [PATCH hci-8.0 7/9] block/block-copy: track known-zero source clusters #VSTOR-134085 Denis V. Lunev
2026-09-30 11:30 ` no-reply
2026-09-30 11:17 ` [PATCH hci-8.0 8/9] block/backup: pre-fill zero_bitmap for full/bitmap #VSTOR-134085 Denis V. Lunev
2026-09-30 11:33 ` no-reply
2026-09-30 11:17 ` [PATCH hci-8.0 9/9] block/block-copy: coalesce write-zeroes tasks #VSTOR-134085 Denis V. Lunev
2026-09-30 11:34 ` no-reply
2026-09-30 12:49 ` Andrey Drobyshev [this message]
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=8e3e6894-0f95-4dfd-ab9c-bad9f2f5dc5d@virtuozzo.com \
--to=andrey.drobyshev@virtuozzo.com \
--cc=den@openvz.org \
--cc=den@virtuozzo.com \
--cc=svt-core@virtuozzo.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.