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.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org