The user-visible problem: $ echo > foo $ qemu-img map --image-opts driver=file,filename=foo,cache.direct=on Offset Length Mapped to File qemu-img: block/io.c:2093: bdrv_co_block_status: Assertion `*pnum && QEMU_IS_ALIGNED(*pnum, align) && align > offset - aligned_offset' failed.
The internal problem: file-posix truncates status requests to the EOF. If the EOF is not aligned at the request_alignment, bdrv_co_block_status() won't like that. See patch 1 for a deeper discussion (including two possible alternatives how we could address the problem). (As I note there, I’ve looked through all block drivers, and I didn’t find any other which could have the same problem. gluster uses the same block-status code, but it doesn’t set a request_alignment. NBD force-aligns the server response in nbd_parse_blockstatus_payload(). qcow2... Should be fine as long as no crypto driver has a block limit exceeding the qcow2 cluster size. And so on.) Patch 2 adds a test. After writing that test, I noticed that we already had one: 109 fails with -c none before patch 1. Er, well, at least the new test is more succinct and has the correct default cache mode, so it will actually do the test if you run ./check without enforcing any cache on a filesystem that supports O_DIRECT. Max Reitz (2): block/file-posix: Unaligned O_DIRECT block-status iotests: Test unaligned raw images with O_DIRECT block/file-posix.c | 17 ++++++++ tests/qemu-iotests/221 | 4 ++ tests/qemu-iotests/253 | 84 ++++++++++++++++++++++++++++++++++++++ tests/qemu-iotests/253.out | 14 +++++++ tests/qemu-iotests/group | 1 + 5 files changed, 120 insertions(+) create mode 100755 tests/qemu-iotests/253 create mode 100644 tests/qemu-iotests/253.out -- 2.21.0