On 10/03/2018 10:49 AM, Eric Blake wrote:
> 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.
> 

I suppose this is in preference to query-block? It would make it easier.

--js

Reply via email to