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