On 01/16/2015 12:52 PM, Max Reitz wrote:
On 2015-01-12 at 11:31, John Snow wrote:
For "dirty-bitmap" sync mode, the block job will iterate through the
given dirty bitmap to decide if a sector needs backup (backup all the
dirty clusters and skip clean ones), just as allocation conditions of
"top" sync mode.
Signed-off-by: Fam Zheng <f...@redhat.com>
Signed-off-by: John Snow <js...@redhat.com>
---
block.c | 5 ++
block/backup.c | 120
++++++++++++++++++++++++++++++++++++++--------
block/mirror.c | 4 ++
blockdev.c | 14 +++++-
hmp.c | 3 +-
include/block/block.h | 1 +
include/block/block_int.h | 2 +
qapi/block-core.json | 11 +++--
qmp-commands.hx | 7 +--
9 files changed, 137 insertions(+), 30 deletions(-)
Since you seem to be intending to rethink the "frozen" state, I'm just
scanning through the series from patch 8 on.
While this patch doesn't seem to have changed much conceptually since
the last version I reviewed, with it applied to master, qemu fails to
build due to Fam's blockdev-backup series (some new calls to
backup_start() which have to be adapted).
Max
Understood. "Frozen" will still exist largely similar to what it doe s
now, but the proposal from fam was to simply fold "enabled/disabled"
into the same status, and perhaps differentiate between a simple
"disabled" state and a "frozen" state by the presence or absence of a
successor.
As for the rebase onto master, here's a v11.5:
https://github.com/jnsnow/qemu/commits/dbm-backup
--
—js
