* [Qemu-devel] Failing QEMU iotest 221
@ 2019-04-28 15:21 Thomas Huth
2019-04-28 15:21 ` Thomas Huth
2019-05-02 22:02 ` Eric Blake
0 siblings, 2 replies; 9+ messages in thread
From: Thomas Huth @ 2019-04-28 15:21 UTC (permalink / raw)
To: Qemu-block, QEMU Developers; +Cc: Kevin Wolf, Max Reitz, Eric Blake
QEMU iotest 221 is failing for me, too, when I run it with -raw:
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},
{ "start": 43009, "length": 511, "depth": 0, "zero": true, "data": false, "offset": OFFSET}]
-[{ "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},
{ "start": 43009, "length": 511, "depth": 0, "zero": true, "data": false, "offset": OFFSET}]
*** done
Failures: 221
Failed 1 of 1 tests
Any ideas how to fix this?
Thomas
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Qemu-devel] Failing QEMU iotest 221
2019-04-28 15:21 [Qemu-devel] Failing QEMU iotest 221 Thomas Huth
@ 2019-04-28 15:21 ` Thomas Huth
2019-05-02 22:02 ` Eric Blake
1 sibling, 0 replies; 9+ messages in thread
From: Thomas Huth @ 2019-04-28 15:21 UTC (permalink / raw)
To: Qemu-block, QEMU Developers; +Cc: Kevin Wolf, Max Reitz
QEMU iotest 221 is failing for me, too, when I run it with -raw:
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},
{ "start": 43009, "length": 511, "depth": 0, "zero": true, "data": false, "offset": OFFSET}]
-[{ "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},
{ "start": 43009, "length": 511, "depth": 0, "zero": true, "data": false, "offset": OFFSET}]
*** done
Failures: 221
Failed 1 of 1 tests
Any ideas how to fix this?
Thomas
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Qemu-devel] Failing QEMU iotest 221
2019-04-28 15:21 [Qemu-devel] Failing QEMU iotest 221 Thomas Huth
2019-04-28 15:21 ` Thomas Huth
@ 2019-05-02 22:02 ` Eric Blake
2019-05-02 22:02 ` Eric Blake
2019-05-03 4:43 ` Thomas Huth
1 sibling, 2 replies; 9+ messages in thread
From: Eric Blake @ 2019-05-02 22:02 UTC (permalink / raw)
To: Thomas Huth, Qemu-block, QEMU Developers; +Cc: Kevin Wolf, Max Reitz
[-- Attachment #1: Type: text/plain, Size: 2353 bytes --]
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
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Qemu-devel] Failing QEMU iotest 221
2019-05-02 22:02 ` Eric Blake
@ 2019-05-02 22:02 ` Eric Blake
2019-05-03 4:43 ` Thomas Huth
1 sibling, 0 replies; 9+ messages in thread
From: Eric Blake @ 2019-05-02 22:02 UTC (permalink / raw)
To: Thomas Huth, Qemu-block, QEMU Developers; +Cc: Kevin Wolf, Max Reitz
[-- Attachment #1: Type: text/plain, Size: 2353 bytes --]
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
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Qemu-devel] Failing QEMU iotest 221
2019-05-02 22:02 ` Eric Blake
2019-05-02 22:02 ` Eric Blake
@ 2019-05-03 4:43 ` Thomas Huth
2019-05-03 4:43 ` Thomas Huth
2019-05-03 20:54 ` Eric Blake
1 sibling, 2 replies; 9+ messages in thread
From: Thomas Huth @ 2019-05-03 4:43 UTC (permalink / raw)
To: Eric Blake, Qemu-block, QEMU Developers; +Cc: Kevin Wolf, Max Reitz
[-- Attachment #1: Type: text/plain, Size: 2689 bytes --]
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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Qemu-devel] Failing QEMU iotest 221
2019-05-03 4:43 ` Thomas Huth
@ 2019-05-03 4:43 ` Thomas Huth
2019-05-03 20:54 ` Eric Blake
1 sibling, 0 replies; 9+ messages in thread
From: Thomas Huth @ 2019-05-03 4:43 UTC (permalink / raw)
To: Eric Blake, Qemu-block, QEMU Developers; +Cc: Kevin Wolf, Max Reitz
[-- Attachment #1: Type: text/plain, Size: 2689 bytes --]
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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Qemu-devel] Failing QEMU iotest 221
2019-05-03 4:43 ` Thomas Huth
2019-05-03 4:43 ` Thomas Huth
@ 2019-05-03 20:54 ` Eric Blake
2019-05-03 20:54 ` Eric Blake
2019-05-06 17:22 ` Eric Blake
1 sibling, 2 replies; 9+ messages in thread
From: Eric Blake @ 2019-05-03 20:54 UTC (permalink / raw)
To: Thomas Huth, Qemu-block, QEMU Developers; +Cc: Kevin Wolf, Max Reitz
[-- Attachment #1: Type: text/plain, Size: 2421 bytes --]
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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Qemu-devel] Failing QEMU iotest 221
2019-05-03 20:54 ` Eric Blake
@ 2019-05-03 20:54 ` Eric Blake
2019-05-06 17:22 ` Eric Blake
1 sibling, 0 replies; 9+ messages in thread
From: Eric Blake @ 2019-05-03 20:54 UTC (permalink / raw)
To: Thomas Huth, Qemu-block, QEMU Developers; +Cc: Kevin Wolf, Max Reitz
[-- Attachment #1: Type: text/plain, Size: 2421 bytes --]
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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Qemu-devel] Failing QEMU iotest 221
2019-05-03 20:54 ` Eric Blake
2019-05-03 20:54 ` Eric Blake
@ 2019-05-06 17:22 ` Eric Blake
1 sibling, 0 replies; 9+ messages in thread
From: Eric Blake @ 2019-05-06 17:22 UTC (permalink / raw)
To: Thomas Huth, Qemu-block, QEMU Developers; +Cc: Kevin Wolf, Max Reitz
[-- Attachment #1: Type: text/plain, Size: 1004 bytes --]
On 5/3/19 3:54 PM, Eric Blake wrote:
>>> 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.
Patch posted in another thread.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2019-05-06 17:28 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-04-28 15:21 [Qemu-devel] Failing QEMU iotest 221 Thomas Huth
2019-04-28 15:21 ` Thomas Huth
2019-05-02 22:02 ` Eric Blake
2019-05-02 22:02 ` Eric Blake
2019-05-03 4:43 ` Thomas Huth
2019-05-03 4:43 ` Thomas Huth
2019-05-03 20:54 ` Eric Blake
2019-05-03 20:54 ` Eric Blake
2019-05-06 17:22 ` Eric Blake
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).