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' 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.

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. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW _______________________________________________ Libguestfs mailing list Libguestfs(a)redhat.com https://www.redhat.com/mailman/listinfo/libguestfs

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...)

On Sat, Aug 01, 2020 at 08:46:11AM +0100, Richard W.M. Jones wrote: > > One thing I noticed which is a bit odd is: > > $ rm file; for f in {0..1023}; do printf '%1024s' .; done > file; stat -c "%b %B" file > 2048 512 > $ rm file; for f in {0..1023}; do printf '%1024s' . >> file; done ; stat -c "%b %B" file > 3968 512 > > The second method is how we currently create the file. Since looking > through the history there seems to be no reason for that I'm going to > push a commit which changes file creation to the first method, and it > may be slightly faster too. > > However it makes me wonder if the file is not laid out in a single > extent and if that might be causing our problems. Being only able > to reproduce this on Koji makes a bit tedious to test theories :-( I pushed this patch and did another test build in Koji, but the issue is still not fixed.

On Mon, Aug 03, 2020 at 04:21:13PM -0500, Eric Blake wrote: > On 8/1/20 12:39 PM, Richard W.M. Jones wrote: > >On Sat, Aug 01, 2020 at 08:46:11AM +0100, Richard W.M. Jones wrote: > >> > >>One thing I noticed which is a bit odd is: > >> > >>$ rm file; for f in {0..1023}; do printf '%1024s' .; done > file; stat -c "%b %B" file > >>2048 512 > >>$ rm file; for f in {0..1023}; do printf '%1024s' . >> file; done ; stat -c "%b %B" file > >>3968 512 > >> > >>The second method is how we currently create the file. Since looking > >>through the history there seems to be no reason for that I'm going to > >>push a commit which changes file creation to the first method, and it > >>may be slightly faster too. > >> > >>However it makes me wonder if the file is not laid out in a single > >>extent and if that might be causing our problems. Being only able > >>to reproduce this on Koji makes a bit tedious to test theories :-( > > > >I pushed this patch and did another test build in Koji, but > >the issue is still not fixed. > > It looks like the real issue at hand is that stat is indeed > reporting allocated size caused by the filesystem pre-emptively > over-allocating based on access patterns (more so when creating the > first file, especially when reopening the file; less so when copying > as the source file size is now stabilized so the copy has less > reason to overshoot). But since the real crux of the test is whether > we managed to punch holes, would it be sufficient to take note of > the original sizes, and merely check that the resulting size has > either shrunk (where the file should now be sparser) or remained > unchanged? > > I'll push a patch along those lines, but as you're the one doing the > koji runs, there's obviously another feedback cycle to go through. Sure I'll give your patch a go once I see it in git, thanks!