Re: [PATCH v2 5/5] iotests: add commit top->base cases to 274

[Eric Blake <eblake@redhat.com>]

On 5/19/20 4:25 PM, Vladimir Sementsov-Ogievskiy wrote:

>> $ ./qemu-img map --output=json top.qcow2
>> [{ "start": 0, "length": 1048576, "depth": 2, "zero": false, "data": 
>> true, "offset": 327680},
>> { "start": 1048576, "length": 1048576, "depth": 0, "zero": true, 
>> "data": false}]
>>
>> I think what we really want is:
>>
>> [{ "start": 0, "length": 1048576, "depth": 2, "zero": false, "data": 
>> true, "offset": 327680},
>> { "start": 1048576, "length": 1048576, "depth": 1, "zero": true, 
>> "data": false}]
>>
>> because then we would be _accurately_ reporting that the zeroes that 
>> we read from 1m-2m come _because_ we read from mid (beyond EOF), which 
>> is different from our current answer that the zeroes come from top 
>> (they don't, because top deferred to mid). 
> 
> Right. This is exactly the logic which I bring to block_status_above and 
> is_allocated_above by this series
> 
> If we fix up qemu-img map output to correctly report zeroes beyond EOF 
> from the correct layer, will that also fix up the bug we are seeing in 
> qemu-img commit?
>>
> 
> No it will not fix it, because img_map has own implementation of 
> block_status_above - get_block_status function in qemu-img.c, which goes 
> through backing chain by itself, and is used only in img_map (not in 
> img_convert). But you are right that it should be fixed too.

You are in a maze of twisty passages, all alike ;)

[Hope neither of us is eaten by a grue by the time we get this series in]

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org