On 09.01.20 12:10, Stefan Hajnoczi wrote:
> This test exercises the block/crypto.c "luks" block driver
> .bdrv_measure() code.
> 
> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
> ---
>  tests/qemu-iotests/282     | 93 ++++++++++++++++++++++++++++++++++++++
>  tests/qemu-iotests/282.out | 30 ++++++++++++
>  tests/qemu-iotests/group   |  1 +
>  3 files changed, 124 insertions(+)
>  create mode 100755 tests/qemu-iotests/282
>  create mode 100644 tests/qemu-iotests/282.out

[...]

> diff --git a/tests/qemu-iotests/282.out b/tests/qemu-iotests/282.out
> new file mode 100644
> index 0000000000..8f4737aef7
> --- /dev/null
> +++ b/tests/qemu-iotests/282.out
> @@ -0,0 +1,30 @@
> +QA output created by 282
> +== measure 1G image file ==
> +
> +required size: 2068480
> +fully allocated size: 1075810304
> +
> +== create 1G image file (size should be no greater than measured) ==
> +
> +Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=1073741824
> +image file size in bytes: 1075810304

It clearly is greater than measured, though.  (Because zero data
generally isn’t encrypted to be zero.)

I also wonder whether it even makes much sense to check the file length,
because I suppose we’re actually interested in how much is allocated.
That is, I think it’s fine to have the file length be greater than
what’s been measured, but the allocated file size shouldn’t be.

But then again the allocated file size may well be greater because of
filesystem shenanigans...

Max