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.
