mirrors/qemu
0
0
Fork 0
mirror of https://github.com/qemu/qemu.git synced 2024-12-01 07:43:35 +08:00
Code Issues Packages Projects Releases Wiki Activity
10cb3336b1
qemu/tests/qemu-iotests/221.out

19 lines
1.3 KiB
Plaintext
Raw Normal View History

iotests: Add test 221 to catch qemu-img map regression Although qemu-img creates aligned files (by rounding up), it must also gracefully handle files that are not sector-aligned. Test that the bug fixed in the previous patch does not recur. It's a bit annoying that we can see the (implicit) hole past the end of the file on to the next sector boundary, so if we ever reach the point where we report a byte-accurate size rather than our current behavior of always rounding up, this test will probably need a slight modification. Signed-off-by: Eric Blake <eblake@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2018-06-12 05:39:27 +08:00
QA output created by 221
=== Check mapping of unaligned raw image ===
iotests: Tweak 221 sizing for different hole granularities For some particular configurations of ext4, sizing an image to 84 sectors + 1 byte causes test failures when the size of the hole is rounded to a 4k alignment. Let's instead size things to 128 sectors + 1 byte, as the 64k boundary is more likely to work with various hole granularities. Reported-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Eric Blake <eblake@redhat.com> Message-Id: <20190506172111.31594-1-eblake@redhat.com> Tested-by: Thomas Huth <thuth@redhat.com>
2019-05-07 01:21:11 +08:00
Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=65537
iotests/221: Discard image before qemu-img map See the new comment for why this should be done. I do not have a reproducer on master, but when using FUSE block exports, this test breaks depending on the underlying filesystem (for me, it works on tmpfs, but fails on xfs, because the block allocated by file-posix has 16 kB there instead of 4 kB). Suggested-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com> Message-Id: <20201207152245.66987-1-mreitz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-12-07 23:22:45 +08:00
discard 65537/65537 bytes at offset 0
64.001 KiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
qemu-img: map: report compressed data blocks Right now "qemu-img map" reports compressed blocks as containing data but having no host offset. This is not very informative. Instead, let's add another boolean field named "compressed" in case JSON output mode is specified. This is achieved by utilizing new allocation status flag BDRV_BLOCK_COMPRESSED for bdrv_block_status(). Also update the expected qemu-iotests outputs to contain the new field. Signed-off-by: Andrey Drobyshev <andrey.drobyshev@virtuozzo.com> Message-ID: <20230907210226.953821-3-andrey.drobyshev@virtuozzo.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2023-09-08 05:02:26 +08:00
[{ "start": 0, "length": 66048, "depth": 0, "present": true, "zero": true, "data": false, "compressed": false, "offset": OFFSET}]
[{ "start": 0, "length": 66048, "depth": 0, "present": true, "zero": true, "data": false, "compressed": false, "offset": OFFSET}]
iotests: Tweak 221 sizing for different hole granularities For some particular configurations of ext4, sizing an image to 84 sectors + 1 byte causes test failures when the size of the hole is rounded to a 4k alignment. Let's instead size things to 128 sectors + 1 byte, as the 64k boundary is more likely to work with various hole granularities. Reported-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Eric Blake <eblake@redhat.com> Message-Id: <20190506172111.31594-1-eblake@redhat.com> Tested-by: Thomas Huth <thuth@redhat.com>
2019-05-07 01:21:11 +08:00
wrote 1/1 bytes at offset 65536
iotests: Add test 221 to catch qemu-img map regression Although qemu-img creates aligned files (by rounding up), it must also gracefully handle files that are not sector-aligned. Test that the bug fixed in the previous patch does not recur. It's a bit annoying that we can see the (implicit) hole past the end of the file on to the next sector boundary, so if we ever reach the point where we report a byte-accurate size rather than our current behavior of always rounding up, this test will probably need a slight modification. Signed-off-by: Eric Blake <eblake@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2018-06-12 05:39:27 +08:00
1 bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
qemu-img: map: report compressed data blocks Right now "qemu-img map" reports compressed blocks as containing data but having no host offset. This is not very informative. Instead, let's add another boolean field named "compressed" in case JSON output mode is specified. This is achieved by utilizing new allocation status flag BDRV_BLOCK_COMPRESSED for bdrv_block_status(). Also update the expected qemu-iotests outputs to contain the new field. Signed-off-by: Andrey Drobyshev <andrey.drobyshev@virtuozzo.com> Message-ID: <20230907210226.953821-3-andrey.drobyshev@virtuozzo.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2023-09-08 05:02:26 +08:00
[{ "start": 0, "length": 65536, "depth": 0, "present": true, "zero": true, "data": false, "compressed": false, "offset": OFFSET},
{ "start": 65536, "length": 1, "depth": 0, "present": true, "zero": false, "data": true, "compressed": false, "offset": OFFSET},
{ "start": 65537, "length": 511, "depth": 0, "present": true, "zero": true, "data": false, "compressed": false, "offset": OFFSET}]
[{ "start": 0, "length": 65536, "depth": 0, "present": true, "zero": true, "data": false, "compressed": false, "offset": OFFSET},
{ "start": 65536, "length": 1, "depth": 0, "present": true, "zero": false, "data": true, "compressed": false, "offset": OFFSET},
{ "start": 65537, "length": 511, "depth": 0, "present": true, "zero": true, "data": false, "compressed": false, "offset": OFFSET}]
iotests: Add test 221 to catch qemu-img map regression Although qemu-img creates aligned files (by rounding up), it must also gracefully handle files that are not sector-aligned. Test that the bug fixed in the previous patch does not recur. It's a bit annoying that we can see the (implicit) hole past the end of the file on to the next sector boundary, so if we ever reach the point where we report a byte-accurate size rather than our current behavior of always rounding up, this test will probably need a slight modification. Signed-off-by: Eric Blake <eblake@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2018-06-12 05:39:27 +08:00
*** done
Reference in New Issue Copy Permalink