Re: [Qemu-devel] [PATCH v3 0/8] block: drive-backup live backup command

[Stefan Hajnoczi <stefanha@redhat.com>]

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