[Libguestfs] nbdkit build failure in Koji

[Nir Soffer]

On Fri, Jul 31, 2020 at 5:12 PM Eric Blake <eblake at 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/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
> Libguestfs at redhat.com
> https://www.redhat.com/mailman/listinfo/libguestfs