On 10/3/18 9:32 AM, Vladimir Sementsov-Ogievskiy wrote:
03.10.2018 02:33, John Snow wrote:
From: Eric Blake <ebl...@redhat.com>
We need an accurate count of the number of bits set in a bitmap
after a merge. In particular, since the merge operation short-circuits
a merge from an empty source, if you have bitmaps A, B, and C where
B started empty, then merge C into B, and B into A, an inaccurate
count meant that A did not get the contents of C.
In the worst case, we may falsely regard the bitmap as empty when
it has had new writes merged into it.
Fixes: be58721db
CC: qemu-sta...@nongnu.org
Signed-off-by: Eric Blake <ebl...@redhat.com>
Signed-off-by: John Snow <js...@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsement...@virtuozzo.com>
Hm, I rememberd:
commit 3260cdfffbf00f33923f5f9f6bef45932d7ac28b
Author: Liang Li <liliang...@didichuxing.com>
Date: Wed Feb 7 11:35:49 2018 -0500
hbitmap: fix missing restore count when finish deserialization
The .count of HBitmap is forgot to set in function
hbitmap_deserialize_finish, let's set it to the right value.
- I always forget to update this field.. We definitely should add some
generic check on it somewhere, at least in tests.
My suggestion (in another thread) was to enhance
x-debug-block-dirty-bitmap-sha256 to include 'count' alongside the
checksum, to make it easier to write such tests.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
