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

[Vladimir Sementsov-Ogievskiy]

On 29.02.24 13:41, 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.
>
> > 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?

Ah, I understand. Conditional just make sense if you don't support "partial 
success", and you want to delete target image in case of failure. And create a new 
one, to restart incremental job.

But anyway, this all could be simply achieved with bitmap-copying/merging API, 
if we allow to pass user-given bitmap to the mirror as working bitmap.

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

Good. It's a golden rule: never make public interfaces which you don't actually need for 
production. I myself sometimes violate it and spend extra time on developing features, 
which we later have to just drop as "not needed downstream, no sense in 
upstreaming".

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

--
Best regards,
Vladimir