Re: [Qemu-devel] [PATCH v6 00/10] block: Incremental backup series

[Denis V. Lunev]

On 18/11/14 19:08, John Snow wrote:
> On 11/18/2014 08:09 AM, Vladimir Sementsov-Ogievskiy wrote:
> > > (3) Data Integrity
> > >
> > > The dirty flag could work something like:
> > >
> > > - If, on first open, the file has the dirty flag set, we need to
> > > discard the bitmap data because we can no longer trust it.
> > > - If the bitmap file is clean, proceed as normal, but take a lock
> > > against any of the bitmap functions to prevent them from marking any
> > > bits dirty.
> > > - On first write to a clean persistent bitmap, delay the write until
> > > we can mark the bitmap as dirty first. This incurs a write penalty
> > > when we try to use the bitmap at first...
> > > - Unlock the bitmap functions and allow them to mark blocks as needed.
> > > - At some point, based on a sync policy, re-commit the dirty
> > > information to the file and mark the file as clean once more and
> > > re-take the persistence lock.
> > Correct me if I'm wrong.

- first of all what we are protecting against? Any QEMU or kernel
crash leads to the disaster. You can not guarantee at all the
consistency between data written to the main file (disk) and data
written to bitmap except if you wait that dirty bitmap is really
updated. In this case you will have performance halved in comparison
with the host (each guest write means 2 IOPS instead of 1)

- this effectively means that we can not be protected against crash

- if we don't we could not care at all about bitmap updates when
QEMU is running. We should write it only on stop/suspend/etc.

This simplifies things a lot.

So, the procedure is simple
- stop main VM by using vm_pause
- open/create bitmap file
- set dirty
- unpause

That's all. If QEMU is running, bitmap is always dirty. The only 
exception is backup creation. New backup means that old bitmap is
synced with dirty clear, new one is created with dirty set and
backup starts working with old bitmap.

Once again. In all other cases we can not guarantee that we will
report _all_ changed blocks to backup software if crash happens
in the middle. One missed block in the bitmap and the entire backup
is blown up.

This also means that (4) aka sync policy is simple. Do this on
close.

> > #Read bitmap:
> > read in blockdev_init, before any write to device, so no lock is needed.
> >
> > #Set bits in bitmap:
> > if bitmap.dirty_flag:
> >     set bits
> > else:
> >     LOCK
> >     set bits
> >     set bitmap.dirty_flag
> >     set dirty_flag in bitmap file
> >     UNLOCK
> >
> > #Sync:
> > if not bitmap.dirty_flag:
> >     skip sync
> > else:
> >     LOCK
> >     save one of bitmap levels (saving the last one is too long and not
> > very good idea, because it is fast-updateing)
> >     unset dirty_flag in bitmap file
> >     unset bitmap.dirty_flag
> >     UNLOCK
> >
> > #Last sync in bdrv_close:
> > Just save the last bitmap level and unset dirty_flag in bitmap file
> >
> > Also.. I'm not quite sure about locking.. As I understand, co-routines
> > in qemu are not running in parallel, is locking required? Or sync timer
> > will not be co-routine based?
> >
> > Best regards,
> > Vladimir
>
> Might be being too informal. I just meant a lock or barrier to prevent
> actual IO throughput until we can confirm the dirty flag has been
> adjusted to indicate that the persistent bitmap is now officially out of
> date. Nothing fancy.
>
> Wasn't trying to imply that we needed threading protection, just
> "locking" the IO until we can configure the bitmap as we need it to be.