qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: John Snow
Subject: Re: [Qemu-devel] [PATCH v11 00/13] block: Incremental backup series
Date: Tue, 13 Jan 2015 14:52:26 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0

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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]