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
