qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Failing QEMU iotest 221


From: Thomas Huth
Subject: Re: [Qemu-devel] Failing QEMU iotest 221
Date: Fri, 3 May 2019 06:43:18 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1

On 03/05/2019 00.02, Eric Blake wrote:
> 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?

ext4 again.

$ stat -f /home/thuth/tmp/qemu-build/tests/qemu-iotests/
  File: "/home/thuth/tmp/qemu-build/tests/qemu-iotests/"
    ID: 1e68b4a412e09716 Namelen: 255     Type: ext2/ext3
Block size: 1024       Fundamental block size: 1024

Maybe the "check" script should report the output of "stat -f", too?

>> 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.

Ok ... sounds like that's definitely something I'd like to leave to you
or one of the block guys to fix.

 Thomas

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]