On 02/22/2018 10:18 AM, Alberto Garcia wrote:
L2 entries for compressed clusters have a field that indicates the
number of sectors used to store the data in the image.

That's however not the size of the compressed data itself, just the
number of sectors where that data is located. The actual data size is
usually not a multiple of the sector size, and therefore cannot be
represented with this field.

The way it works is that QEMU reads all the specified sectors and
starts decompressing the data until there's enough to recover the
original uncompressed cluster. If there are any bytes left that
haven't been decompressed they are simply ignored.

One consequence of this is that even if the size field is larger than
it needs to be QEMU can handle it just fine: it will read more data
from disk but it will ignore the extra bytes.

(is that true even for the corner case when the size field points beyond the end of the image? But not important to the meat of the patch)

This test creates an image with a compressed cluster that uses 5
sectors (2.5 KB), increases the size field to the maximum (8192
sectors, or 4 MB) and verifies that the data can be read without

This test is important because while the decompressed data takes
exactly one cluster, the maximum value allowed in the compressed size
field is twice the cluster size. So although QEMU won't produce images
with such large values we need to make sure that it can handle them.

Aditionally, this patch also tests that decreasing the size corrupts


the image since the original data can no longer be recovered.

Signed-off-by: Alberto Garcia <be...@igalia.com>
  tests/qemu-iotests/122     | 22 ++++++++++++++++++++++
  tests/qemu-iotests/122.out |  9 +++++++++
  2 files changed, 31 insertions(+)

+# Reduce size of compressed data to 4 sectors: this corrupts the image
+poke_file "$TEST_IMG".1 $((0x800000)) "\x40\x06"
+$QEMU_IO -c "read  -P 0x11 0 4M" "$TEST_IMG".1 2>&1 | _filter_qemu_io | 

Should we run 'qemu-img check' at this point, to see if that likewise diagnoses the image as broken? (And if it doesn't, should it be able to?)

+# Increase size of compressed data to the maximum (8192 sectors)
+# This makes QEMU read more data (8192 sectors instead of 5), but the
+# decompression algorithm stops once we have enough to restore the
+# uncompressed cluster, so the rest of the data is ignored
+poke_file "$TEST_IMG".1 $((0x800000)) "\x7f\xfe"
+$QEMU_IO -c "read  -P 0x11 0 4M" "$TEST_IMG".1 2>&1 | _filter_qemu_io | 

But what you added is a strict improvement, so
Reviewed-by: Eric Blake <ebl...@redhat.com>

Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

Reply via email to