From: Fiona Ebner <f.ebner@proxmox.com>
To: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>,
qemu-devel@nongnu.org
Cc: qemu-block@nongnu.org, armbru@redhat.com, eblake@redhat.com,
hreitz@redhat.com, kwolf@redhat.com, jsnow@redhat.com,
f.gruenbichler@proxmox.com, t.lamprecht@proxmox.com,
mahaocong@didichuxing.com, xiechanglong.d@gmail.com,
wencongyang2@huawei.com
Subject: Re: [PATCH v2 2/4] mirror: allow specifying working bitmap
Date: Wed, 8 May 2024 14:43:51 +0200 [thread overview]
Message-ID: <eddff0eb-470d-4e1e-bec4-c06f27fb5a9d@proxmox.com> (raw)
In-Reply-To: <14e568d4-ae82-4eaa-921f-1927a9b81ceb@proxmox.com>
Am 07.05.24 um 14:15 schrieb Fiona Ebner:
> Am 02.04.24 um 22:14 schrieb Vladimir Sementsov-Ogievskiy:
>> On 07.03.24 16:47, Fiona Ebner wrote:
>>> +# @bitmap: The name of a bitmap to use as a working bitmap for
>>> +# sync=full mode. This argument must be not be present for other
>>> +# sync modes and not at the same time as @granularity. The
>>> +# bitmap's granularity is used as the job's granularity. When
>>> +# the target is a diff image, i.e. one that should only contain
>>> +# the delta and was not synced to previously, the target's
>>> +# cluster size must not be larger than the bitmap's granularity.
>>
>> Could we check this? Like in block_copy_calculate_cluster_size(), we can
>> check if target does COW, and if not, we can check that we are safe with
>> granularity.
>>
>
> The issue here is (in particular) present when the target does COW, i.e.
> in qcow2 diff images, allocated clusters which end up with partial data,
> when we don't have the right cluster size. Patch 4/4 adds the check for
> the target's cluster size.
>
Sorry, no. What I said is wrong. It's just that the test does something
very pathological and does not even use COW/backing files. All the
mirror targets are separate diff images there. So yes, we can do the
same as block_copy_calculate_cluster_size() and the issue only appears
in the same edge cases as for backup where we can error out early. This
also applies to copy-mode=write-blocking AFAICT.
>>> +# For a diff image target, using copy-mode=write-blocking should
>>> +# not be used, because unaligned writes will lead to allocated
>>> +# clusters with partial data in the target image!
>>
>> Could this be checked?
>>
>
> I don't think so. How should we know if the target already contains data
> from a previous full sync or not?
>
> Those caveats when using diff images are unfortunate, and users should
> be warned about them of course, but the main/expected use case for the
> feature is to sync to the same target multiple times, so I'd hope the
> cluster size check in patch 4/4 and mentioning the edge cases in the
> documentation is enough here.
>
next prev parent reply other threads:[~2024-05-08 12:44 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-07 13:47 [PATCH v2 0/4] mirror: allow specifying working bitmap Fiona Ebner
2024-03-07 13:47 ` [PATCH v2 1/4] qapi/block-core: avoid the re-use of MirrorSyncMode for backup Fiona Ebner
2024-03-08 7:34 ` Markus Armbruster
2024-04-01 12:51 ` Vladimir Sementsov-Ogievskiy
2024-03-07 13:47 ` [PATCH v2 2/4] mirror: allow specifying working bitmap Fiona Ebner
2024-03-08 7:41 ` Markus Armbruster
2024-04-02 20:14 ` Vladimir Sementsov-Ogievskiy
2024-05-07 12:15 ` Fiona Ebner
2024-05-08 12:43 ` Fiona Ebner [this message]
2024-03-07 13:47 ` [PATCH v2 3/4] iotests: add test for bitmap mirror Fiona Ebner
2024-03-07 13:47 ` [PATCH v2 4/4] blockdev: mirror: check for target's cluster size when using bitmap Fiona Ebner
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=eddff0eb-470d-4e1e-bec4-c06f27fb5a9d@proxmox.com \
--to=f.ebner@proxmox.com \
--cc=armbru@redhat.com \
--cc=eblake@redhat.com \
--cc=f.gruenbichler@proxmox.com \
--cc=hreitz@redhat.com \
--cc=jsnow@redhat.com \
--cc=kwolf@redhat.com \
--cc=mahaocong@didichuxing.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=t.lamprecht@proxmox.com \
--cc=vsementsov@yandex-team.ru \
--cc=wencongyang2@huawei.com \
--cc=xiechanglong.d@gmail.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 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 read-only IMAP folder(s) and NNTP newsgroup(s).