From: John Snow <jsnow@redhat.com>
To: qemu-devel@nongnu.org
Cc: "kwo >> Kevin Wolf" <kwolf@redhat.com>,
Fam Zheng <famz@redhat.com>,
"mre >> Max Reitz" <mreitz@redhat.com>,
vladimir Sementsov-Ogievskiy <vsementsov@parallels.com>,
Stefan Hajnoczi <stefanha@redhat.com>,
"pbon >> Paolo Bonzini" <pbonzini@redhat.com>
Subject: Re: [Qemu-devel] [2.3 PATCH v7 00/10] block: Incremental backup series
Date: Tue, 25 Nov 2014 14:55:00 -0500 [thread overview]
Message-ID: <5474DE94.3040008@redhat.com> (raw)
In-Reply-To: <1416944800-17919-1-git-send-email-jsnow@redhat.com>
On 11/25/2014 02:46 PM, John Snow wrote:
> 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
>
> ==
>
> This is the next iteration of Fam's incremenetal backup feature.
> I have since taken this over from him and have (slowly) worked through
> the feedback to the last version of his patch and have made many
> tiny little edits.
>
> -John.
>
> v7: (highlights)
> - First version being authored by jsnow
> - Addressed most list feedback from V6, many small changes.
> All feedback was either addressed on-list (as a wontfix) or patched.
> - Replaced all error_set with error_setg
> - Replaced all bdrv_find with bdrv_lookup_bs()
> - Adjusted the max granularity to share a common function with
> backup/mirror that attempts to "guess" a reasonable default.
> It clamps between [4K,64K] currently.
> - The BdrvDirtyBitmap object now counts granularity exclusively in
> bytes to match its interface.
> It leaves the sector granularity concerns to HBitmap.
> - Reworked the backup loop to utilize the hbitmap iterator.
> There are some extra concerns to handle arrhythmic cases where the
> granularity of the bitmap does not match the backup cluster size.
> This iteration works best when it does match, but it's not a
> deal-breaker if it doesn't -- it just gets less efficient.
> - Reworked the transactional functions so that abort() wouldn't "undo"
> a redundant command. They now have been split into a prepare and a
> commit function (with state) and do not provide an abort command.
> - Added a block_dirty_bitmap_lookup(device, name, errp) function to
> shorten a few of the commands added in this series, particularly
> qmp_enable, qmp_disable, and the transaction preparations.
>
> v6: Re-send of v5.
>
> v5: Rebase to master.
>
> v4: Last version tailored by Fam Zheng.
>
> Fam Zheng (10):
> qapi: Add optional field "name" to block dirty bitmap
> qmp: Add block-dirty-bitmap-add and block-dirty-bitmap-remove
> block: Introduce bdrv_dirty_bitmap_granularity()
> hbitmap: Add hbitmap_copy
> block: Add bdrv_copy_dirty_bitmap and bdrv_reset_dirty_bitmap
> qmp: Add block-dirty-bitmap-enable and block-dirty-bitmap-disable
> qmp: Add support of "dirty-bitmap" sync mode for drive-backup
> qapi: Add transaction support to block-dirty-bitmap-{add, enable,
> disable}
> qmp: Add dirty bitmap 'enabled' field in query-block
> qemu-iotests: Add tests for drive-backup sync=dirty-bitmap
>
> block-migration.c | 2 +-
> block.c | 114 +++++++++++++++++++--
> block/backup.c | 128 ++++++++++++++++++++----
> block/mirror.c | 16 ++-
> blockdev.c | 226 +++++++++++++++++++++++++++++++++++++++++-
> hmp.c | 4 +-
> include/block/block.h | 17 +++-
> include/block/block_int.h | 6 ++
> include/qemu/hbitmap.h | 8 ++
> qapi-schema.json | 5 +-
> qapi/block-core.json | 123 ++++++++++++++++++++++-
> qmp-commands.hx | 66 +++++++++++-
> tests/qemu-iotests/056 | 33 +++++-
> tests/qemu-iotests/056.out | 4 +-
> tests/qemu-iotests/iotests.py | 8 ++
> util/hbitmap.c | 16 +++
> 16 files changed, 722 insertions(+), 54 deletions(-)
>
Script missed the CCs. Sigh.
For convenience:
Github: https://github.com/jnsnow/qemu/tree/dbm-backup
Git: https://github.com/jnsnow/qemu.git
Thanks,
--js
prev parent reply other threads:[~2014-11-25 19:55 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-25 19:46 [Qemu-devel] [2.3 PATCH v7 00/10] block: Incremental backup series John Snow
2014-11-25 19:46 ` [Qemu-devel] [2.3 PATCH v7 01/10] qapi: Add optional field "name" to block dirty bitmap John Snow
2014-11-26 11:22 ` Max Reitz
2014-11-25 19:46 ` [Qemu-devel] [2.3 PATCH v7 02/10] qmp: Add block-dirty-bitmap-add and block-dirty-bitmap-remove John Snow
2014-11-26 12:19 ` Max Reitz
2014-11-26 15:39 ` John Snow
2014-11-26 15:53 ` Max Reitz
2014-11-27 9:16 ` Markus Armbruster
2014-11-25 19:46 ` [Qemu-devel] [2.3 PATCH v7 03/10] block: Introduce bdrv_dirty_bitmap_granularity() John Snow
2014-11-26 12:29 ` Max Reitz
2014-11-25 19:46 ` [Qemu-devel] [2.3 PATCH v7 04/10] hbitmap: Add hbitmap_copy John Snow
2014-11-26 12:32 ` Max Reitz
2014-11-25 19:46 ` [Qemu-devel] [2.3 PATCH v7 05/10] block: Add bdrv_copy_dirty_bitmap and bdrv_reset_dirty_bitmap John Snow
2014-11-26 12:43 ` Max Reitz
2014-11-26 16:01 ` Eric Blake
2014-11-27 9:05 ` Markus Armbruster
2014-11-25 19:46 ` [Qemu-devel] [2.3 PATCH v7 06/10] qmp: Add block-dirty-bitmap-enable and block-dirty-bitmap-disable John Snow
2014-11-26 12:51 ` Max Reitz
2014-11-25 19:46 ` [Qemu-devel] [2.3 PATCH v7 07/10] qmp: Add support of "dirty-bitmap" sync mode for drive-backup John Snow
2014-11-26 14:19 ` Max Reitz
2014-11-25 19:46 ` [Qemu-devel] [2.3 PATCH v7 08/10] qapi: Add transaction support to block-dirty-bitmap-{add, enable, disable} John Snow
2014-11-26 14:44 ` Max Reitz
2014-11-25 19:46 ` [Qemu-devel] [2.3 PATCH v7 09/10] qmp: Add dirty bitmap 'enabled' field in query-block John Snow
2014-11-26 14:49 ` Max Reitz
2014-11-25 19:46 ` [Qemu-devel] [2.3 PATCH v7 10/10] qemu-iotests: Add tests for drive-backup sync=dirty-bitmap John Snow
2014-11-26 14:52 ` Max Reitz
2014-11-25 19:55 ` John Snow [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5474DE94.3040008@redhat.com \
--to=jsnow@redhat.com \
--cc=famz@redhat.com \
--cc=kwolf@redhat.com \
--cc=mreitz@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@redhat.com \
--cc=vsementsov@parallels.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).