[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFC 0/4] mirror: implement incremental and bitmap modes
From: |
Fiona Ebner |
Subject: |
Re: [RFC 0/4] mirror: implement incremental and bitmap modes |
Date: |
Thu, 29 Feb 2024 11:41:21 +0100 |
User-agent: |
Mozilla Thunderbird |
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
- [RFC 1/4] drive-mirror: add support for sync=bitmap mode=never, (continued)
Re: [RFC 0/4] mirror: implement incremental and bitmap modes, Vladimir Sementsov-Ogievskiy, 2024/02/28
- Re: [RFC 0/4] mirror: implement incremental and bitmap modes,
Fiona Ebner <=