Re: [Qemu-devel] [PATCH v11 00/13] block: Incremental backup series

[John Snow <jsnow@redhat.com>]

Minor update to the github version of this patchset that brings it 
inline with the recent block pull into master. It also drops a duplicate 
patch that has since made it upstream.

Not re-posting yet to allow time for review and critique.

--js

On 01/12/2015 11:30 AM, John Snow wrote:
> Welcome to version 11. I hope you are enjoying our regular newsletter.
>
> This patchset enables the in-memory part of the incremental backup
> feature. A patchset by Vladimir Sementsov-Ogievskiy enables the
> migration of in-memory dirty bitmaps, and a future patchset will
> enable the storage and retrieval of dirty bitmaps to and from permanent
> storage.
>
> Enough changes have been made that most Reviewed-By lines from
> previous iterations have been removed. (Sorry!)
>
> This series was originally authored by Fam Zheng;
> his cover letter is included below.
>
> ~John Snow
>
> =================================================================
>
> This is the in memory part of the incremental backup feature.
>
> With the added commands, we can create a bitmap on a block
> backend, from which point of time all the writes are tracked by
> the bitmap, marking sectors as dirty. Later, we call drive-backup
> and pass the bitmap to it, to do an incremental backup.
>
> See the last patch which adds some tests for this use case.
>
> Fam
>
> =================================================================
>
> For convenience, this patchset is available on github:
>                  https://github.com/jnsnow/qemu/commits/dbm-backup
>
> v11:
>
>   - Instead of copying BdrvDirtyBitmaps and keeping a pointer to the
>     object we were copied from, we instead "freeze" a bitmap in-place
>     without copying it. On success, we thaw and delete the bitmap.
>     On failure, we merge the bitmap with a "successor," which is an
>     anonymous bitmap attached as a child that records writes for us
>     for the duration of the backup operation.
>
>     This means that incremental backups can NEVER BE RETRIED in a
>     deterministic fashion. If an incremental backup fails on a set
>     of dirty sectors {x}, and a new set of dirty sectors {y} are
>     introduced during the backup, then any possible retry action
>     on an incremental backup can only operate on {x,y}. There is no
>     way to get an incremental backup "as it would have been."
>
>     So, the failure mode for incremental backup is to try again,
>     and the resulting image will simply be a differential from the
>     last successful dirty bitmap backup.
>
>   - Removed hbitmap_copy and bdrv_dirty_bitmap_copy.
>
>   - Added a small fixup patch:
>     - Update all granularity fields to be uint64_t.
>     - Update documentation around BdrvDirtyBitmap structure.
>
>   - Modified transactions to obey frozen attribute of BdrvDirtyBitmaps.
>
>   - Added frozen attribute to the info query.
>