qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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
Subject: Re: [RFC 0/4] mirror: implement incremental and bitmap modes
Date: Thu, 29 Feb 2024 11:41:21 +0100	[thread overview]
Message-ID: <195fe8a5-02c2-4cc4-bc41-095f6477b676@proxmox.com> (raw)
In-Reply-To: <217803cb-fced-4dce-87f3-9892b2f97dce@yandex-team.ru>

Am 28.02.24 um 17:24 schrieb Vladimir Sementsov-Ogievskiy:
> On 16.02.24 13:55, Fiona Ebner wrote:
>> Previous discussion from when this was sent upstream [0] (it's been a
>> while). I rebased the patches and re-ordered and squashed like
>> suggested back then [1].
>>
>> This implements two new mirror modes:
>>
>> - bitmap mirror mode with always/on-success/never bitmap sync mode
>> - incremental mirror mode as sugar for bitmap + on-success
>>
>> Use cases:
>> * Possibility to resume a failed mirror later.
>> * Possibility to only mirror deltas to a previously mirrored volume.
>> * Possibility to (efficiently) mirror an drive that was previously
>>    mirrored via some external mechanism (e.g. ZFS replication).
>>
>> We are using the last one in production without any issues since about
>> 4 years now. In particular, like mentioned in [2]:
>>
>>> - create bitmap(s)
>>> - (incrementally) replicate storage volume(s) out of band (using ZFS)
>>> - incrementally drive mirror as part of a live migration of VM
>>> - drop bitmap(s)
> 
> Actually which mode you use, "never", "always" or "conditional"? Or in
> downstream you have different approach?
> 

We are using "conditional", but I think we don't really require any
specific mode, because we drop the bitmaps after mirroring (even in
failure case). Fabian, please correct me if I'm wrong.

> Why am I asking:
> 
> These modes (for backup) were developed prior to
> block-dirty-bitmap-merge command, which allowed to copy bitmaps as you
> want. With that API, we actually don't need all these modes, instead
> it's enough to pass a bitmap, which would be _actually_ used by mirror.
> 
> So, if you need "never" mode, you just copy your bitmap by
> block-dirty-bitmap-add + block-dirty-bitmap-merge, and pass a copy to
> mirror job.
> 
> Or, you pass your bitmap to mirror-job, and have a "always" mode.
> 
> And I don't see, why we need a "conditional" mode, which actually just
> drops away the progress we actually made. (OK, we failed, but why to
> drop the progress of successfully copied clusters?)
> 

I'm not sure actually. Maybe John remembers?

I see, I'll drop the 'bitmap-mode' in the next version if nobody
complains :)

> 
> Using user-given bitmap in the mirror job has also an additional
> advantage of live progress: up to visualization of disk copying by
> visualization of the dirty bitmap contents.
> 

Best Regards,
Fiona



  reply	other threads:[~2024-02-29 10:42 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-16 10:55 [RFC 0/4] mirror: implement incremental and bitmap modes Fiona Ebner
2024-02-16 10:55 ` [RFC 1/4] drive-mirror: add support for sync=bitmap mode=never Fiona Ebner
2024-02-21  6:55   ` Markus Armbruster
2024-02-21  9:21     ` Fiona Ebner
2024-02-16 10:55 ` [RFC 2/4] drive-mirror: add support for conditional and always bitmap sync modes Fiona Ebner
2024-02-16 10:55 ` [RFC 3/4] mirror: move some checks to qmp Fiona Ebner
2024-02-16 10:55 ` [RFC 4/4] iotests: add test for bitmap mirror Fiona Ebner
2024-02-28 16:00 ` [RFC 0/4] mirror: implement incremental and bitmap modes Vladimir Sementsov-Ogievskiy
2024-02-28 16:06   ` Vladimir Sementsov-Ogievskiy
2024-02-29 10:11     ` Fiona Ebner
2024-02-29 11:48       ` Vladimir Sementsov-Ogievskiy
2024-02-29 12:47         ` Fiona Ebner
2024-03-06 13:44           ` Fiona Ebner
2024-03-07  9:20             ` Vladimir Sementsov-Ogievskiy
2024-02-28 16:24 ` Vladimir Sementsov-Ogievskiy
2024-02-29 10:41   ` Fiona Ebner [this message]
2024-02-29 12:00     ` Vladimir Sementsov-Ogievskiy
2024-02-29 14:50       ` Fiona Ebner
2024-03-01 14:14         ` Vladimir Sementsov-Ogievskiy
2024-03-01 14:52           ` Fiona Ebner
2024-03-01 15:02             ` Vladimir Sementsov-Ogievskiy
2024-03-01 15:14               ` Fiona Ebner
2024-03-01 15:46                 ` Vladimir Sementsov-Ogievskiy
2024-03-04  7:50                   ` Fiona Ebner
2024-03-04  9:02     ` Fabian Grünbichler

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=195fe8a5-02c2-4cc4-bc41-095f6477b676@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 \
    /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).