On Tue, May 21, 2013 at 10:58:47AM +0000, Dietmar Maurer wrote: > > >> True, but that would happen only in case the host crashes. Even for > > >> a QEMU crash the changes would be safe, I think. They would be > > >> written back when the persistent dirty bitmap's mmap() area is > > >> unmapped, during process exit. > > > > > > I'd err on the side of caution, mark the persistent dirty bitmap while > > > QEMU is running. Discard the file if there was a power failure. > > > > Agreed. Though this is something that management must do manually, isn't > > it? > > QEMU cannot distinguish a SIGKILL from a power failure, while management > > can afford treating SIGKILL as a power failure. > > > > > It really depends what the dirty bitmap users are doing. It could be > > > okay to have a tiny chance of missing a modification but it might not. > > I just want to mention that there is another way to do incremental backups. > Instead > of using a dirty bitmap, you can compare the content, usually using a digest > (SHA1) on clusters.
Reading gigabytes of data from disk is expensive though. I guess they keep a Merkle tree so it's easy to find out which parts of the image must be transferred without re-reading the entire image. That sounds like more work than a persistent dirty bitmap. The advantage is that while dirty bitmaps are consumed by a single user, the Merkle tree can be used to sync up any number of replicas. > That way you can also implement async replication to a remote site (like MS > do). Sounds like rsync. Stefan