On 6/15/20 12:09 PM, Peter Krempa wrote:
Upcoming patches are going to rewrite and semantically modify how bitmaps are handled during blockjobs. This is possible as incremental backup is not yet fully enabled. As the changes are going to be incompatible with any current test data remove all test cases for bitmap handling during checkpoint deletion, incremental backups, block commit, block copy, and bitmap validation operations. The tests will be gradually added back later after the code and test-data is refactored. Signed-off-by: Peter Krempa <pkrempa@xxxxxxxxxx> ---
49 files changed, 2909 deletions(-)
And this is the point where we have to commit on which interface we will stick to once we allow incremental backups by default rather than just by opting in. With your idea of keeping multiple bitmaps active, we may need to tweak qemu to be more efficient at how it stores bitmap information (for example, instead of having each guest write modify the in-memory representation of all active bitmaps, which only get flushed to disk when closing the guest, we could instead have qemu store guest writes into a single in-memory bitmap, then merge that into all active bitmaps when flushing) - but that's for qemu to worry about. In the meantime, if your n ew proposed bitmap handling is easier to manage in libvirt, even if it costs more work in current qemu, I think we can live with that.
I'm reluctant to ack this patch until I've seen the rest of the series adding support back in, but unless something major turns up in the rest of the series, the approach of a clean slate followed by a new implementation is reasonable enough.
-- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org
