On Tue, May 21, 2013 at 10:30:22AM +0200, Paolo Bonzini wrote: > Il 21/05/2013 09:31, Stefan Hajnoczi ha scritto: > > On Mon, May 20, 2013 at 09:23:43AM +0200, Paolo Bonzini wrote: > >> Il 20/05/2013 08:24, Stefan Hajnoczi ha scritto: > >>>>> You only need to fdatasync() before every guest flush, no? > >>> No, you need to set the dirty bit before issuing the write on the > >>> host. Otherwise the image data may be modified without setting the > >>> appropriate dirty bit. That would allow data modifications to go > >>> undetected! > >> > >> But data modifications can go undetected until the guest flush returns, > >> can't they? > > > > You are thinking about it from the guest perspective - if a flush has > > not completed yet then there is no guarantee that the write has reached > > disk. > > > > But from a host perspective the dirty bitmap should be conservative so > > that the backup application can always restore a bit-for-bit identical > > copy of the disk image. It would be weird if writes can sneak in > > unnoticed. > > 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. 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. Stefan
