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

[Eric Blake]

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