Re: [Libguestfs] nbdkit build failure in Koji
On Fri, Jul 31, 2020 at 5:12 PM Eric Blake <eblake(a)redhat.com> 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/d74824cf7c8b352f9045e949dc636c7207a41ee...
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/7676d97e49eb1399ed5256e08786c...
Then the tests pick some of the available storage as needed:
https://github.com/oVirt/ovirt-imageio/blob/7676d97e49eb1399ed5256e08786c...
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
Libguestfs(a)redhat.com
https://www.redhat.com/mailman/listinfo/libguestfs