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 -- 2.0.4