0

I run stuff like this in a bash script:

set -x
time convert 'cat.png' -quality 100 test.webp
time convert 'cat.png' -quality 100 test.jpeg

du -h test.webp test.jpeg

It would often print output like this:

+ du -h test.webp test.jpeg
512  test.webp
387K test.jpeg

512 bytes for the webp file seems impossibly small, right?

When I run the du -h afterwards in the terminal, it shows a different size (which is more reasonable).

I know that du without --apparent-size shows the underlying storage size (e.g. number of blocks multiplied by some factor), but I would still expect that to always print the same, deterministic result.

What is going on?

nh2
  • 1,721
  • 2
  • 14
  • 22

1 Answers1

0

On some file systems, like ZFS and Btrfs, the result of du without --apparent-size does vary over time.

There is no guarantee that the file system does not delay, re-arrange, compress, deduplicate, or otherwise modify the physical storage over time.

Thus plain du can give different results any second.

Detail example: Running strace -v on the du invocation shows shows the data returned from the stat-type syscall; first:

newfstatat(AT_FDCWD, "test.webp", { ... st_blksize=131072, st_blocks=1, st_size=464124, ...

and shortly after:

newfstatat(AT_FDCWD, "test.webp", { ... st_blksize=131072, st_blocks=1029, st_size=464124, ...
nh2
  • 1,721
  • 2
  • 14
  • 22
  • 1
    You can use the stat command if you want to get those numbers without using strace: stat -c '%B %4b %n' test.webp would have given 131072 1029 test.webp for the second measurement. – Neil Mayhew May 26 '20 at 13:49