Re: [Libguestfs] nbdkit build failure in Koji

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.