On 2015-03-10 09:54:47, Fam Zheng wrote:
> On Tue, 03/10 09:30, Zhang Haoyu wrote:
> >
> > On 2015-03-10 08:29:19, Fam Zheng wrote:
> > > On Mon, 03/09 16:14, Zhang Haoyu wrote:
> > > > Hi John, Vladimir
> > > > We can using active block commit to implement incremental backup
> > > > without guest disruption,
> > > > e.g.,
> > > > origin <= A <= B <= C <= current BDS,
> > > > a new external snapshot will be produced before every time backup,
> > > > we can migrate A, B, C, ... to destination,
> > > > then commit_active_start() the unneeded snapshot in source or
> > > > destination end.
> > > >
> > > > So, comparing with above mechanism,
> > > > what's the advantages of the incremental backup implemented by John and
> > > > Vladimir?
> > >
> > > We can't migrate A, B, C because they are buried in the backing chain
> > > under
> > > "current BDS".
> > I think we can backup the incremental image(e.g., A, B, C) to destination
> > in top mode,
> > although I haven't read the code in detail, it can work theoretically, I
> > think.
>
> No, we don't have any command do that.
>
Is it worthy to implement it?
And does qemu support commit any external snapshot to its backing file?
> >
> > > Even if we do that, there will be severe IO amplification
> > > compared to the dirty bitmap way.
> > >
> > Yes, block-commit will produce extra IO.
> > But regarding incremental backup, when guest IO is performed,
> > will the corresponding dirty bit be synchronized to qcow2 image
> > simultaneously?
>
> No, that would have a huge performance penalty. It will only be synced
> at shutdown and or periodically, therefore it has the same implications with
> other cache, such as page cache or block driver metadata cache.
>
> > if no, if source VM is shut-down in non-normal way, like killed by force or
> > by mistake or server poweroff suddenly,
> > some dirty bits maybe lost, then full copy is needed.
>
> Yes, it is a reasonable rule.
>
> > >
> > drive-backup is not incremental backup, full copy is needed in every time
> > backup,
> > so it dosen't meet our requirements.
>
> I didn't mean drive-backup already provides incremental backup, but we do need
> it to implement it (see the patch series posted by John Snow).
>
> Thanks,
> Fam
