qemu-block
[Top][All Lists]
Advanced

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

Re: [Qemu-block] Failing QEMU iotest 221


From: Eric Blake
Subject: Re: [Qemu-block] Failing QEMU iotest 221
Date: Fri, 3 May 2019 15:54:13 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1

On 5/2/19 11:43 PM, Thomas Huth wrote:
> 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

Odd that it is so small; these days, most ext4 systems have a block size
of 4k.

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

Wouldn't hurt, although that doesn't tell us all of the file system
tuning parameters that might be important to reproducing a problem.


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

I can certainly prepare a patch that widens the file to 64k+1 instead of
43008+1, but since I can't (yet) reproduce the failure, I'd be relying
on you to verify that it makes a difference.

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

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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