Re: [Qemu-devel] [RFC] introduce bitmap to bdrv_commit to trackdirtysector

["Zhang Haoyu" <zhanghy@sangfor.com.cn>]

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