Il 16/05/2013 09:47, Stefan Hajnoczi ha scritto: > On Thu, May 16, 2013 at 02:16:20PM +0800, Wenchao Xia wrote: >> After checking the code, I found it possible to add delta data backup >> support also, If an additional dirty bitmap was added. > > I've been thinking about this. Incremental backups need to know which > blocks have changed, but keeping a persistent dirty bitmap is expensive > and unnecessary. > > Backup applications need to support the full backup case anyway for > their first run. Therefore we can keep a best-effort dirty bitmap which > is persisted only when the guest is terminated cleanly. If the QEMU > process crashes then the on-disk dirty bitmap will be invalid and the > backup application needs to do a full backup next time. > > The advantage of this approach is that we don't need to fdatasync(2) > before every guest write operation.
You only need to fdatasync() before every guest flush, no? Paolo >> Compared with >> current solution, I think it is doing COW at qemu device level: >> >> qemu device >> | >> general block layer >> | >> virtual format layer >> | >> ----------------------- >> | | >> qcow2 vmdk.... >> >> This will make things complicated when more works comes, a better >> place for block COW, is under general block layer. Maybe later we >> can adjust block for it. > > I don't consider block jobs to be "qemu device" layer. It sounds like > you think the code should be in bdrv_co_do_writev()? > > The drive-backup operation doesn't really affect the source > BlockDriverState, it just needs to intercept writes. Therefore it seems > cleaner for the code to live separately (plus we reuse the code for the > block job loop which copies out data while the guest is running). > Otherwise we would squash all of the blockjob code into block.c and it > would be an even bigger mess than it is today :-). > >