How to count total size of directory, and why `du` output differs between copies of directory?

Because I am clearly missing something here:

 $ cp -a CENTOS-chroot 1 $ cp -a CENTOS-chroot 2 $ cp -a CENTOS-chroot 3 $ cp -a CENTOS-chroot 4 $ du --block-size=1 -s 1 2 3 4
6320304128 1
6320304128 2
6320234496 3
6320238592 4

This happens both on HDD and NVME SSD with ext4 on two Linux machines (Manjaro and Centos7) I have.

2 Answers

Don't forget that du reports disk usage at the raw underlying filesystem level, not at the apparent "file size" level... see --apparent-size.

--apparent-size

print apparent sizes, rather than disk usage; although the apparent size is usually smaller, it may be larger due to holes in ('sparse') files, internal fragmentation, indirect blocks, and the like

See also -b, which might be a better option to giving --block-size=1 and --apparent-size together:

-b, --bytes

equivalent to --apparent-size --block-size=1

... so, does du -bs ${dir} produce better results?

Given that most / all filesystems are based on fixed-size blocks, it's very common to see the apparent "File Size" (i.e number of bytes you would be able to read from a file) differ to the actual space used on-disk (i.e: number of bytes consumed to store this file and its metadata).

For example:

• Small files will typically use more space than they "should"... on a filesystem with 4KiB blocks, it isn't possible to have a file use less than 4KiB of on-disk space, even if it only stores one byte.
• Large files are commonly constructed out of a number of "extents"... an extent will describe where to locate the data for a portion of the file. Extents consume disk space too.
  • In a filesystem without any fragmentation (i.e: large gaps of unused space), it's possible to have a "large" file with only one extent.
  • In a filesystem with lots of fragmentation (i.e: lots of data all over the place, leaving small gaps between data), that same "large" file may actually have a number of extents used to indicate where the data is stored.

It depends entirely on the order that files were palced on disk, and the algorithms that are used to seek out contiguous blocks of free space.

You could have a very space-efficient filesystem that continuously and carefully re-arranges all files such that they are perfectly tessellated like a well played Tetris board. The filesystem would end up spending a lot of time searching for suitable space, and the performance would suffer drastically.

Equally, you could have a very fragmentation-oriented filesystem, that just uses the first unused blocks, and skipping used blocks. Writing data on a first-gap basis is also going to decimate your performance.

Instead, we prefer to balance things, spending some time (but not too much) to seek out a contiguous block of unused space that will contain the entirety of the data we're trying to write.

The fragmentation level of a file isn't directly tied to the order that the copy commants were issued - in part because of the "try, but not too hard" approach outlined above.

In summary, the data stored in these two directories should be the same, but the disk usage (even for the same data) is unlikely to match perfectly.

There are a number of options to verify that the stored data is the same - try diff (no output is good, it'll report the changes):

diff -qr "${src}" "${dst}"

To complicate this even further, it's possible that sparse files can use significantly less than expected:

$ truncate -s 100M x
$ ls -l x
-rw-r--r-- 1 attie attie 104857600 Jul 14 17:15 x
$ du --block-size 1 x
0 x
$ du -bs x
104857600 x

The block and extent layout of an ext4 file system is dependent on the fill rate and fragmentation of the file system.

This implies, that a file system with more files on it will likely use up (slightly) different space for additional files, than on an empty file system. In your case, the 4th copy will take up more space than the 1st copy.