unusual behavior of loop dev with backing file in tmpfs

[Lukas Czerner <lczerner@redhat.com>]

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