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