tests/qemu-iotests/291 | 4 ++-- tests/qemu-iotests/291.out | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-)
Depending on the granularity of holes and amount of metadata consumed
by a file, the 'disk size:' number of 'qemu-img info' is not reliable.
Adjust our test to use a different set of filters to avoid spurious
failures.
Reported-by: Kevin Wolf <kwolf@redhat.com>
Fixes: cf2d1203dc
Signed-off-by: Eric Blake <eblake@redhat.com>
---
tests/qemu-iotests/291 | 4 ++--
tests/qemu-iotests/291.out | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/tests/qemu-iotests/291 b/tests/qemu-iotests/291
index 3ca83b9cd1f7..910326b0ec55 100755
--- a/tests/qemu-iotests/291
+++ b/tests/qemu-iotests/291
@@ -77,7 +77,7 @@ echo
# Only bitmaps from the active layer are copied
$QEMU_IMG convert --bitmaps -O qcow2 "$TEST_IMG.orig" "$TEST_IMG"
-$QEMU_IMG info "$TEST_IMG" | _filter_img_info --format-specific
+_img_info --format-specific
# But we can also merge in bitmaps from other layers. This test is a bit
# contrived to cover more code paths, in reality, you could merge directly
# into b0 without going through tmp
@@ -87,7 +87,7 @@ $QEMU_IMG bitmap --add --merge b0 -b "$TEST_IMG.base" -F $IMGFMT \
$QEMU_IMG bitmap --merge tmp -f $IMGFMT "$TEST_IMG" b0
$QEMU_IMG bitmap --remove --image-opts \
driver=$IMGFMT,file.driver=file,file.filename="$TEST_IMG" tmp
-$QEMU_IMG info "$TEST_IMG" | _filter_img_info --format-specific
+_img_info --format-specific
echo
echo "=== Check bitmap contents ==="
diff --git a/tests/qemu-iotests/291.out b/tests/qemu-iotests/291.out
index 8c62017567e9..9f661515b417 100644
--- a/tests/qemu-iotests/291.out
+++ b/tests/qemu-iotests/291.out
@@ -24,7 +24,7 @@ qemu-img: Format driver 'raw' does not support bitmaps
image: TEST_DIR/t.IMGFMT
file format: IMGFMT
virtual size: 10 MiB (10485760 bytes)
-disk size: 4.39 MiB
+cluster_size: 65536
Format specific information:
compat: 1.1
compression type: zlib
@@ -44,7 +44,7 @@ Format specific information:
image: TEST_DIR/t.IMGFMT
file format: IMGFMT
virtual size: 10 MiB (10485760 bytes)
-disk size: 4.48 MiB
+cluster_size: 65536
Format specific information:
compat: 1.1
compression type: zlib
--
2.27.0
Am 08.06.2020 um 21:56 hat Eric Blake geschrieben: > Depending on the granularity of holes and amount of metadata consumed > by a file, the 'disk size:' number of 'qemu-img info' is not reliable. > Adjust our test to use a different set of filters to avoid spurious > failures. > > Reported-by: Kevin Wolf <kwolf@redhat.com> > Fixes: cf2d1203dc > Signed-off-by: Eric Blake <eblake@redhat.com> Thanks, applied to the block branch. Kevin
On 6/9/20 8:32 AM, Kevin Wolf wrote: > Am 08.06.2020 um 21:56 hat Eric Blake geschrieben: >> Depending on the granularity of holes and amount of metadata consumed >> by a file, the 'disk size:' number of 'qemu-img info' is not reliable. >> Adjust our test to use a different set of filters to avoid spurious >> failures. >> >> Reported-by: Kevin Wolf <kwolf@redhat.com> >> Fixes: cf2d1203dc >> Signed-off-by: Eric Blake <eblake@redhat.com> > > Thanks, applied to the block branch. It has a conflict with one of Vladimir's bitmaps patches that I'm about to send a pull request for; so I'll resolve the conflict and include it in my bitmaps tree instead, and you can drop it from yours. I'm assuming I can add your Acked-by since you were willing to stage it. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org
Am 09.06.2020 um 22:46 hat Eric Blake geschrieben: > On 6/9/20 8:32 AM, Kevin Wolf wrote: > > Am 08.06.2020 um 21:56 hat Eric Blake geschrieben: > > > Depending on the granularity of holes and amount of metadata consumed > > > by a file, the 'disk size:' number of 'qemu-img info' is not reliable. > > > Adjust our test to use a different set of filters to avoid spurious > > > failures. > > > > > > Reported-by: Kevin Wolf <kwolf@redhat.com> > > > Fixes: cf2d1203dc > > > Signed-off-by: Eric Blake <eblake@redhat.com> > > > > Thanks, applied to the block branch. > > It has a conflict with one of Vladimir's bitmaps patches that I'm about to > send a pull request for; so I'll resolve the conflict and include it in my > bitmaps tree instead, and you can drop it from yours. I'm assuming I can > add your Acked-by since you were willing to stage it. Ok, no problem. Kevin
© 2016 - 2024 Red Hat, Inc.