On 8/4/20 4:42 AM, Richard W.M. Jones wrote:
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!
Unfortunately no this didn't fix it. The log is:
https://kojipkgs.fedoraproject.org//work/tasks/9782/48609782/build.log
nozero2.img (for example) was originally:
nozero2.img: 2048 allocated blocks of size 512 bytes, total size 1048576
but when we test it later it has grown to 4096 blocks:
+ for i in {2..6}
++ stat -c %b nozero2.img
+ test 4096 '!=' 2048
+ echo 'nozero2.img was trimmed by mistake'
nozero2.img was trimmed by mistake
+ fail=1
So it has been "trimmed" from 2048 to 4096 blocks. Perhaps we should
use -lt in that test to detect if the file got smaller?
Well, the point is that it wasn't trimmed - the nozero filter let
literal zeroes be written in rather than attempting a trim. But still,
it is odd that writing literal zeroes in place made the file occupy more
reserved space, even though the file size is unchanged.
I wonder if changing the file to be 2 megabytes in size, but only
writing zeroes to the first megabyte, would be a more reliable way to
avoid the file system thinking that because we just wrote zeroes all the
way to the current EOF that we are likely to grow the file size, in
order to thwart its preemptive allocations. But you also have a point
that merely forbidding a shrinking file is an acceptable test (the fact
that the file grew is not nice, but the file did not become sparse, and
that's all we really cared about).
Also I was interested in what filesystem the builders are using (since
I still cannot reproduce any of this without Koji). So I added
‘stat -f .’ in the %check section. It printed:
File: "."
ID: fc0200000000 Namelen: 255 Type: xfs
Block size: 4096 Fundamental block size: 4096
Blocks: Total: 33538048 Free: 25172957 Available: 25172957
Inodes: Total: 67108864 Free: 66469270
I believe the builder is running Fedora 32, at least going by the
kernel version. (This surprised me as I thought they were running
RHEL.)
Rich.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org
_______________________________________________
Libguestfs mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/libguestfs
