On 6/6/19 1:41 PM, John Snow wrote:
When adding new persistent dirty bitmaps, we only check constraints
against currently stored bitmaps, and ignore the pending number and size
of any bitmaps yet to be stored.
Rework the "can_store" and "remove" interface to explicit "add" and "remove",
and begin keeping track of the queued burden when adding new bitmaps.
Reported-by: aihua liang <ali...@redhat.com>
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1712636
John Snow (5):
block/qcow2-bitmap: allow bitmap_list_load to return an error code
block/dirty-bitmap: Refactor bdrv_can_store_new_bitmap
block/dirty-bitmap: rework bdrv_remove_persistent_dirty_bitmap
block/qcow2-bitmap: Count queued bitmaps towards nb_bitmaps
block/qcow2-bitmap: Count queued bitmaps towards directory_size
Is this series worth reviving as a v2, as it solves a corner-case bug?
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org
