On Fri, Jul 31, 2020 at 5:12 PM Eric Blake <[email protected]> wrote: > > 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).
In qemu iotets we check how much space an empty file is using to avoid issues with filesystem allocating extra blocks. https://github.com/qemu/qemu/blob/d74824cf7c8b352f9045e949dc636c7207a41eee/tests/qemu-iotests/175#L82 Not sure this is relevant to this case since this grows from 2048 blocks to 4096, not 1 extra block. In ovit we avoid these issues by testing on filesytems we control instead on random filesystem provided by the CI environment. We use this: https://github.com/nirs/userstorage The idea is that you configure some combinations you want to test, like: https://github.com/oVirt/ovirt-imageio/blob/master/storage.py Prepare this storage as root before running the tests: https://github.com/oVirt/ovirt-imageio/blob/7676d97e49eb1399ed5256e08786c006ce5ff9ee/Makefile#L17 Then the tests pick some of the available storage as needed: https://github.com/oVirt/ovirt-imageio/blob/7676d97e49eb1399ed5256e08786c006ce5ff9ee/daemon/test/backends_file_test.py#L40 Tests using the user_file fixture above are run once for every parameter, so we know the code works on 3 different filesystems with 2 logical block size. Nir > > 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 > > _______________________________________________ > Libguestfs mailing list > [email protected] > https://www.redhat.com/mailman/listinfo/libguestfs _______________________________________________ Libguestfs mailing list [email protected] https://www.redhat.com/mailman/listinfo/libguestfs
