From: "Fabian Grünbichler" <f.gruenbichler@proxmox.com>
To: Max Reitz <mreitz@redhat.com>, qemu-devel@nongnu.org
Cc: Kevin Wolf <kwolf@redhat.com>, John Snow <jsnow@redhat.com>,
Markus Armbruster <armbru@redhat.com>,
qemu-block@nongnu.org
Subject: Re: [RFC qemu 0/6] mirror: implement incremental and bitmap modes
Date: Thu, 03 Sep 2020 12:13:21 +0200 [thread overview]
Message-ID: <1599127031.9uxdp5h9o2.astroid@nora.none> (raw)
In-Reply-To: <d35a76de-78d5-af56-0b34-f7bd2bbd3733@redhat.com>
On August 21, 2020 3:03 pm, Max Reitz wrote:
> On 18.02.20 11:07, Fabian Grünbichler wrote:
>
> [Sorry :/]
same, I've been meaning to ping/pick this back up but other stuff got in
the way. so thanks for the reminder to get this upstream ;)
>
>> picking up on John's in-progress patch series from last summer, this is
>> a stab at rebasing and adding test cases for the low-hanging fruits:
>>
>> - bitmap mirror mode with always/on-success/never bitmap sync mode
>> - incremental mirror mode as sugar for bitmap + on-success
>>
>> Fabian Grünbichler (4):
>> mirror: add check for bitmap-mode without bitmap
>> mirror: switch to bdrv_dirty_bitmap_merge_internal
>> iotests: add test for bitmap mirror
>> mirror: move some checks to QMP
>>
>> John Snow (2):
>> drive-mirror: add support for sync=bitmap mode=never
>> drive-mirror: add support for conditional and always bitmap sync modes
>
> Looks reasonable to me. I would indeed merge patches 2 through 4 into a
> single one, and perhaps switch patches 5 and 6.
>
> Also, we still need an S-o-b from John on patch 2.
>
> I have one question: When the mirror job completes successfully (or is
> cancelled “successfully”), the bitmap is always fully cleared when the
> job completes, right? (Unless in “never” mode.)
I have to take a closer look as well, it's been a while ;) IIRC the idea
was that failed mirrors would allow re-using the bitmap for a next
attempt, unless the mode is always. we are not using that feature (yet)
though (see below).
> Not that I think we should change the current implementation of “clear
> sync_bitmap; merge dirty_bitmap into sync_bitmap;”. Just a question for
> understanding.
>
>
> Soo... What’s the plan?
I'll rebase, squash as suggested and resend next week! I am not sure how
the S-O-B by John is supposed to enter the mix - should I just include
it in the squashed patch (which would be partly authored, but
not-yet-signed-off by him otherwise?)? do you pick it up once he's
replied with one?
FWIW, with been running with this for quite a while downstream with no
issues, but we are only using the following part:
- 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)
so no fancy semi-permanent bitmap that gets re-used here. I've been
toying with implementing some sort of generic replication feature akin
to zfs send/recv though, but given that we only have built-in persistent
bitmaps with qcow2 and the chance of some other tool or the user messing
up other image formats is high, the safe usage scenarios are a bit
limited.
we do use such long-running bitmaps for our new backup driver though,
and it works quite well there!
next prev parent reply other threads:[~2020-09-03 10:22 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-18 10:07 [RFC qemu 0/6] mirror: implement incremental and bitmap modes Fabian Grünbichler
2020-02-18 10:07 ` [RFC qemu 1/6] drive-mirror: add support for sync=bitmap mode=never Fabian Grünbichler
2020-02-18 10:07 ` [RFC qemu 2/6] drive-mirror: add support for conditional and always bitmap sync modes Fabian Grünbichler
2020-02-18 10:07 ` [RFC qemu 3/6] mirror: add check for bitmap-mode without bitmap Fabian Grünbichler
2020-02-18 10:07 ` [RFC qemu 4/6] mirror: switch to bdrv_dirty_bitmap_merge_internal Fabian Grünbichler
2020-02-18 10:07 ` [RFC qemu 5/6] iotests: add test for bitmap mirror Fabian Grünbichler
2020-02-18 10:07 ` [RFC qemu 6/6] mirror: move some checks to QMP Fabian Grünbichler
2020-02-18 10:43 ` [RFC qemu 0/6] mirror: implement incremental and bitmap modes no-reply
2020-02-25 21:54 ` John Snow
2020-04-03 11:34 ` Fabian Grünbichler
2020-08-21 13:03 ` Max Reitz
2020-08-24 15:54 ` John Snow
2020-09-03 10:13 ` Fabian Grünbichler [this message]
2020-09-03 11:04 ` Max Reitz
2020-09-03 12:38 ` Kevin Wolf
2020-09-03 12:57 ` Max Reitz
2020-09-03 13:23 ` Kevin Wolf
2020-09-03 13:36 ` Fabian Grünbichler
2020-09-03 13:43 ` Kevin Wolf
2020-09-03 13:51 ` Max Reitz
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=1599127031.9uxdp5h9o2.astroid@nora.none \
--to=f.gruenbichler@proxmox.com \
--cc=armbru@redhat.com \
--cc=jsnow@redhat.com \
--cc=kwolf@redhat.com \
--cc=mreitz@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
/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.