Re: [RFC 0/4] mirror: implement incremental and bitmap modes

[Fabian Grünbichler]

On February 29, 2024 11:41 am, Fiona Ebner wrote:
> 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.

indeed, we don't really care for our current use case (and don't have
any other planned either, AFAIK), the bitmap is used only for the
duration of a single mirror, and always discarded at the end.

>> 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 :)

it was probably just done to mimic the backup interface, if that is not
desired, dropping it is probably a good idea.