Two ext4 mounts, fully rsynced, same total file amount, but different total byte size. Why?

Question

Problem

We have two mount points on two disks, both are the exact same type. Both disks are formatted ext4.

An rsync command with options to synchronize from source to destination is performed.

After the rsync is performed, the following data is shown:

Disk 1 - Source

315.8 GiB (339,148,905,125) - 476,038 files, 21,975 sub-folders.

Disk 2 - Destination

315.8 GiB (339,098,108,411) - 476,038 files, 21,975 sub-folders.

Difference

50,796,714 bytes (~50 Mb)

Command Used

rsync -r -t -p -o -g -v --progress --delete --ignore-existing -s /media/user/disk1 /media/user/disk2

---

Question

Why are the total byte sizes different?

---

Update

The suggested answer was attempted. The byte size between the source and the destination showed no improvement in size equalization.

Suggested answer command included the -a and -l switches, adding archiving and symbolic link transfer:

rsync -a -r -t -p -o -g -v -l --progress --delete --ignore-existing -s /media/user/disk1 /media/user/disk2

(Results)

Disk 1 - Source

315.8 GiB (339,148,905,125) - 476,038 files, 21,975 sub-folders.

Disk 2 - Destination

315.8 GiB (339,098,108,411) - 476,038 files, 21,975 sub-folders.

Difference

50,796,714 bytes (~50 Mb)

---

Status

Problem not solved.

---

Further Research

A similar problem found on SuperUser:

https://superuser.com/questions/442539/why-do-two-directory-hierarchies-that-are-in-sync-have-different-sizes

From ServerFault:

Rsync size is difference from source to destination

---

Update 2

Requests were made for du and df outputs, and the results were:

root@system:/# du -s /media/user/disk1

332172440 /media/user/disk1

root@system:/# du -s /media/user/disk2/

332119568 /media/user/disk2/

root@system:/# df /media/user/disk1

Filesystem 1K-blocks Used Available Use% Mounted on

/dev/sdc 528316088 332243868 169212316 67% /media/user/disk1

root@system:/# df /media/user/disk2/

Filesystem 1K-blocks Used Available Use% Mounted on

/dev/sdb 528316088 332190996 169265164 67% /media/user/disk2

Thus there is still a difference of 52,872 between disk1 and disk2.

Answer 1

For many reasons. For example, you don't use -a or -l, so the symbolic links are converted to normal files. You don't use -H so hard links become normal files.

And there is also a phenomenon on Unix/Linux, that a removed file still consumes the space until all the processes that had it opened decide to close it. Might there be open files on Destination before rsync?

Lastly, it could be a problem with Source's sparse files not being properly handled, but it's less likely since rsync usually deals nicely with them.

PS rsync FAQ gives some other possibilities (source):

2. If your target is slightly smaller than your source the likely cause is a difference in directory sizes. This is simply due to how directories allocate disk space and can't really be helped. I have devised a quick shell command to add up all of the file sizes in the current directory without including the directory sizes:

echo `find . -type f -ls | awk '{print $7 "+"}'`0 | bc

5. There are also differences in filesystem types, block sizes, file slack overhead, etc. that can cause the outcome to be different.

tune2fs -l /dev/your_block_device | grep -i 'block size'

6. If you have checked all of this and you are still bugged by an unexplained size difference then I would like to point out that simple sizes are not a very useful check for completeness or accuracy on a data copying operation. It doesn't check the contents of the files at all and it is subject to variations I explained above. I would suggest using an actual file verification utility such as cfv to verify your files using real cryptographic hashes. The cfv utility is very similar to the simple md5sum utility except that it is recursive, faster, and has a %completion bar.