Hello, I've noticed unusual test failure in e2fsprogs testsuite (m_assume_storage_prezeroed) where we use mke2fs to create a file system on loop device backed in file on tmpfs. For some reason sometimes the resulting file number of allocated blocks (stat -c '%b' /tmp/file) differs, but it really should not. I was trying to create a simplified reproducer and noticed the following behavior on mainline kernel (v5.16-rc2-54-g5d9f4cf36721) # truncate -s16M /tmp/file # stat -c '%b' /tmp/file 0 # losetup -f /tmp/file # stat -c '%b' /tmp/file 672 That alone is a little unexpected since the file is really supposed to be empty and when copied out of the tmpfs, it really is empty. But the following is even more weird. We have a loop setup from above, so let's assume it's /dev/loop0. The following should be executed in quick succession, like in a script. # dd if=/dev/zero of=/dev/loop0 bs=4k # blkdiscard -f /dev/loop0 # stat -c '%b' /tmp/file 0 # sleep 1 # stat -c '%b' /tmp/file 672 Is that expected behavior ? From what I've seen when I use mkfs instead of this simplified example the number of blocks allocated as reported by stat can vary a quite a lot given more complex operations. The file itself does not seem to be corrupted in any way, so it is likely just an accounting problem. Any idea what is going on there ? Thanks! -Lukas
