Patch 2:
The bdrv_is_allocated() functions may return a number of zero sectors
e.g. if a sector beyond the image end has been queried. Respect this
case in qemu-io's map implementation so it doesn't run into an infinite
loop (https://bugs.launchpad.net/qemu/+bug/1356969).
Patch 1:
In that bug report, bdrv_co_get_block_status() fell through to the
underlying file to get additional information (whether the sectors are
zeroed). However, the offset reported by the image format (qcow2) was
beyond the size of the underlying file and so this second query returned
only zero clusters which replaced the actual number of sectors queried
in the "formatted" (on qcow2 level) image. But because errors from this
second call are ignored, the number of sector queried successfully
should be ignored as well, which makes qemu-io -c map actually work for
that bug report.
Patch 3 adds a test for patch 1; I could not conceive a test for patch 2
which patch 1 would not already catch, but patch 2 should be simple
enough not to require a test anyway.
Thanks to patch 3, this series depends on my previous series
"[PATCH v10 00/14] qemu-img: Implement commit like QMP"
(strictly speaking only on patch 11 of that series which adds
_filter_qemu_img_map() to tests/qemu-iotests/common.filter).
Max Reitz (3):
block: Ignore allocation size in underlying file
qemu-io: Respect early image end for map
iotests: Add test for map commands
block.c | 6 +++--
qemu-io-cmds.c | 5 +++-
tests/qemu-iotests/102 | 64 ++++++++++++++++++++++++++++++++++++++++++++++
tests/qemu-iotests/102.out | 11 ++++++++
tests/qemu-iotests/group | 1 +
5 files changed, 84 insertions(+), 3 deletions(-)
create mode 100755 tests/qemu-iotests/102
create mode 100644 tests/qemu-iotests/102.out