On 7/31/20 7:07 AM, Richard W.M. Jones wrote:
Hi Eric,
I wonder if you have any thoughts about this build failure in
tests/test-nozero.sh?
https://koji.fedoraproject.org/koji/taskinfo?taskID=48259627
log:
https://kojipkgs.fedoraproject.org//work/tasks/9762/48259762/build.log
The error is “nozero6.img was trimmed by mistake”. I added “set -x”
to the script earlier today so we can see exactly what's wrong, and it
is that:
++ stat -c %b nozero2.img
++ stat -c %b nozero6.img
+ test 4096 '!=' 2048
+ echo 'nozero6.img was trimmed by mistake'
Hmm, maybe it is file-system dependent (not all filesystems reserve the
same amount of space for a sparse file - that's something that qemu
iotests keep on hitting).
AFAICT what this means is that nozero2.img is growing during the test
(from 2048 to 4096 blocks). When I run the test locally this file
stays at 2048 blocks the whole time, and the test does not fail.
Growing a small amount but still being sparse is different from growing
a huge amount to be non-sparse altogether. I'll have to double-check
what the test is actually doing (the size of the files involved) and see
if we can relax the test into allowing a range of sizes that show a file
is still reasonably sparse. But knowing what filesystem koji is using
may matter (for example, if this is something that shows up on btrfs but
not ext4, that would explain why koji fails when I pass locally...)
One other unfortunate problem is that Fedora is having lots of
toolchain problems right now (see Fedora devel list passim) so we
cannot really be sure that *any* other tool we are using has been
built correctly :-( I've already disabled LTO in qemu and libguestfs,
but possibly there are other toolchain bugs.
Rich.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization:
qemu.org |
libvirt.org