Re: [Qemu-block] Failing QEMU iotest 221

[Eric Blake]

On 4/28/19 10:21 AM, Thomas Huth wrote:
> QEMU iotest 221 is failing for me, too, when I run it with -raw:

Which filesystem?

> 
> tests/qemu-iotests$ ./check -raw 221
> QEMU          -- 
> "/home/thuth/tmp/qemu-build/tests/qemu-iotests/../../x86_64-softmmu/qemu-system-x86_64"
>  -nodefaults -machine accel=qtest
> QEMU_IMG      -- 
> "/home/thuth/tmp/qemu-build/tests/qemu-iotests/../../qemu-img" 
> QEMU_IO       -- 
> "/home/thuth/tmp/qemu-build/tests/qemu-iotests/../../qemu-io"  --cache 
> writeback -f raw
> QEMU_NBD      -- 
> "/home/thuth/tmp/qemu-build/tests/qemu-iotests/../../qemu-nbd" 
> IMGFMT        -- raw
> IMGPROTO      -- file
> PLATFORM      -- Linux/x86_64 thuth 3.10.0-957.10.1.el7.x86_64
> TEST_DIR      -- /home/thuth/tmp/qemu-build/tests/qemu-iotests/scratch
> SOCKET_SCM_HELPER -- 
> /home/thuth/tmp/qemu-build/tests/qemu-iotests/socket_scm_helper
> 
> 221         - output mismatch (see 221.out.bad)
> --- /home/thuth/devel/qemu/tests/qemu-iotests/221.out 2019-04-23 
> 16:43:12.000000000 +0200
> +++ /home/thuth/tmp/qemu-build/tests/qemu-iotests/221.out.bad 2019-04-28 
> 17:18:52.000000000 +0200
> @@ -7,10 +7,10 @@
>  [{ "start": 0, "length": 43520, "depth": 0, "zero": true, "data": false, 
> "offset": OFFSET}]
>  wrote 1/1 bytes at offset 43008
>  1 bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
> -[{ "start": 0, "length": 40960, "depth": 0, "zero": true, "data": false, 
> "offset": OFFSET},
> -{ "start": 40960, "length": 2049, "depth": 0, "zero": false, "data": true, 
> "offset": OFFSET},
> +[{ "start": 0, "length": 43008, "depth": 0, "zero": true, "data": false, 
> "offset": OFFSET},
> +{ "start": 43008, "length": 1, "depth": 0, "zero": false, "data": true, 
> "offset": OFFSET},

Ugh. Hole granularities are file-system specific, so we need to figure
out some way to fuzz the input. It might also be possible to pick nicer
size numbers - perhaps if the test image is sized at 64k+1 instead of
43009 (84*512, but NOT evenly divisible by 4k), the +1 byte is more
likely to be directly one a hole boundary, rather than being somewhere
that causes rounding the hole boundary 2k earlier because of 4k or 64k
sizing constraints.

> Any ideas how to fix this?
> 
>  Thomas
> 

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

signature.asc
Description: OpenPGP digital signature