On Wed, May 21, 2025 at 11:54:03AM +0200, Fiona Ebner wrote: > Hi, > > Am 15.05.25 um 04:28 schrieb Eric Blake: > > +do_test full ignore off full > > for me, this one fails irregularly (more than 50% of the time) with: > -Destination is full; expected full > +Destination is unknown; expected full > > My file system is ext4 inside a virtual machine. > > [I] febner@dev8 ~/repos/qemu/build/tests/qemu-iotests (master) [1]> findmnt > > --target . > > TARGET SOURCE FSTYPE OPTIONS > > /home/febner/repos /dev/sdb ext4 rw,relatime > > The virtual disk is an LVM image. When the test fails, I consistently > get 20975616 bytes rather than 20971520 bytes as the result of > disk_usage(), i.e. it has one 4 KiB block more. ls -l will still report > 20971520 bytes as the length, qemu-img compare succeeds.
Odd, but should be something I can cater to by treating any value >= 20M (rather than exactly 20M) as fully allocated (the test still does the qemu-img compare to ensure that the actual length compares correctly, even if the allocated length was slightly overallocated due to filesystem magic). > > After the image creation, i.e. job1, the allocation is still as expected: > > +20971520 > > /home/febner/repos/qemu/build/tests/qemu-iotests/scratch/raw-file-mirror-sparse/t.raw > > +-rw-r--r-- 1 febner febner 20971520 May 21 11:18 > > /home/febner/repos/qemu/build/tests/qemu-iotests/scratch/raw-file-mirror-sparse/t.raw > > Only after mirroring, i.e. job2, it will be larger: > > +20975616 > > /home/febner/repos/qemu/build/tests/qemu-iotests/scratch/raw-file-mirror-sparse/t.raw > > +-rw-r--r-- 1 febner febner 20971520 May 21 11:18 > > /home/febner/repos/qemu/build/tests/qemu-iotests/scratch/raw-file-mirror-sparse/t.raw Weird, but filesystems have been known to do weird things. So the test should be updated to tolerate it. > > Some more information: > > > [I] febner@dev8 ~/repos/qemu/tests/qemu-iotests/tests (master)> sudo > > filefrag > > /home/febner/repos/qemu/build/tests/qemu-iotests/scratch/raw-file-mirror-sparse/t.raw > > -e > > Filesystem type is: ef53 > > File size of > > /home/febner/repos/qemu/build/tests/qemu-iotests/scratch/raw-file-mirror-sparse/t.raw > > is 20971520 (5120 blocks of 4096 bytes) > > ext: logical_offset: physical_offset: length: expected: flags: > > 0: 0.. 15: 36233216.. 36233231: 16: > > 1: 16.. 2047: 36233232.. 36235263: 2032: > > unwritten > > 2: 2048.. 2559: 36239360.. 36239871: 512: 36235264: > > 3: 2560.. 4095: 36239872.. 36241407: 1536: > > unwritten > > 4: 4096.. 5119: 33792000.. 33793023: 1024: 36241408: > > last,unwritten,eof > > /home/febner/repos/qemu/build/tests/qemu-iotests/scratch/raw-file-mirror-sparse/t.raw: > > 3 extents found > > Note that one of the offsets is not 4KiB-aligned: > > 36239360%4096 > > 2048 > > I suppose that is the reason? > > > [I] febner@dev8 ~/repos/qemu/tests/qemu-iotests/tests (master)> stat > > /home/febner/repos/qemu/build/tests/qemu-iotests/scratch/raw-file-mirror-sparse/t.raw > > File: > > /home/febner/repos/qemu/build/tests/qemu-iotests/scratch/raw-file-mirror-sparse/t.raw > > Size: 20971520 Blocks: 40968 IO Block: 4096 regular file > > Device: 8,16 Inode: 4866541 Links: 1 > > Access: (0644/-rw-r--r--) Uid: ( 1000/ febner) Gid: ( 1000/ febner) > > Access: 2025-05-21 11:18:37.622692254 +0200 > > Modify: 2025-05-21 11:18:37.540686997 +0200 > > Change: 2025-05-21 11:18:37.540686997 +0200 > > Birth: 2025-05-21 11:18:37.463682059 +0200 > > I also tried it on my host, where the filesystem is ZFS using > compression, and there, 'du' will already report a lower value after > creating the image, because of compression. And even without compression > it seems that preallocation=full on ZFS is somehow async :/ > > > [I] febner@enia ~/qemu/build/tests/qemu-iotests (master)> qemu-img create > > my.raw 20M -f raw -o preallocation=full > > Formatting 'my.raw', fmt=raw size=20971520 preallocation=full > > [I] febner@enia ~/qemu/build/tests/qemu-iotests (master)> du --block-size=1 > > my.raw > > 512 my.raw > > [I] febner@enia ~/qemu/build/tests/qemu-iotests (master)> du --block-size=1 > > my.raw > > 20980224 my.raw That one may be a bit harder to work around, but I'll give it a shot while I'm patching the first one. -- Eric Blake, Principal Software Engineer Red Hat, Inc. Virtualization: qemu.org | libguestfs.org
