Re: [Qemu-devel] Failing QEMU iotest 221
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 signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] Failing QEMU iotest 221
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.0 +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 signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] Failing QEMU iotest 221
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.out2019-04-23 >> 16:43:12.0 +0200 >> +++ /home/thuth/tmp/qemu-build/tests/qemu-iotests/221.out.bad >> 2019-04-28 17:18:52.0 +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 signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] Failing QEMU iotest 221
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.0 +0200 > +++ /home/thuth/tmp/qemu-build/tests/qemu-iotests/221.out.bad 2019-04-28 > 17:18:52.0 +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