Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm using rsync to sync two folders

rsync -arzv --times --delete-after --relative -e ssh user@host:path/./media/ ~/path/

and it says everything is good, but the destination reports:

$ du -s path/media/
18335196    site_media/media/

and the source reports:

$ du -s path/media/
18473500        site_media/media/

When I dig down into the problem, all the files are the same size, but the directories differ in size. Why? Both are VM's running ubuntu, the source is on 11.04 and the destination is on 12.04 LTS

I understand why they don't add up to the same numbers, what I'd like to understand is why the folders report different sizes.

share|improve this question

migrated from Jun 28 '12 at 9:47

This question came from our site for professional and enthusiast programmers.

Since it's two different VMs running different major versions of Ubuntu I'd suspect block size of the filesystem is the culprit. du reports how much of the disk is being used, not the sum of the file sizes. A subtle, yet important distinction.

If you have a file that is 1 byte in size and your block size is 1KB then du will report 1KB as used. If the block size is 4KB then it will report 4KB used. If that file is 1025B then it would report 2KB used for the 1KB block size and 4KB for the 4KB. And if the file is 4097B then it will be reported as 5KB on the 1KB block size and 8KB on the 4KB block size.

This sequence demonstrates this behavior:

$ touch foo ; du -h foo
  0B    foo
$ echo -n 1 > foo ; du -h foo
4.0K    foo

Use this command to show the block size of your filesystems:

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

(Obviously, replace /dev/sda1 with the appropriate block device.)

If it's different, there's your discrepancy.

A better way to check for the exactness of the rsync is to hash your files and compare. Here's an example:

find path/media -exec openssl sha1 {} + | sort > ~/hashes

Then diff the hashes files.

share|improve this answer

There are many sources of differences when using du. Check man for reference. I have been facing such problem on aix too. In manual, there is an option --apparent-size, which describes these differences quite well. Also - mind the block size for which the size is calculated by du (default is 1024 bytes, but may vary depending on system). You will have to cope with it using a command which shows exact size of files (ls or find), which was the way, I've used to solve this.

share|improve this answer

Another possibility is that rsync's--archive flag doesn't preserve hardlinks by default. If you use hard links then that might be your problem as well.

share|improve this answer

Chances are good that you've been adding and deleting files in your directories for a long time. The space from unlinked files in a directory is recycled, but perhaps future additions couldn't use that free space directly.

I presume you haven't mirrored every file link and unlink that's ever taken place -- it'd be easy for the source to have had ten or twenty times more files linked and unlinked than the destination -- and the destination is thus not as fragmented.

If you perform some super-complicated directory calisthenics you may be able to reduce the sizes of the directories on the source; it'd look something like this:

mkdir foo
mv media/* foo
rmdir media
mv foo media

Note that this won't save anywhere near enough drive space to make it worth while. It's just a fun toy, if that...

share|improve this answer
Does moving a directory on the same filesystem help? AFAIK, only allocation table entries are changed in this case. If I wanted to defragment files in a directory, I would make a copy instead. – ipip Jun 28 '12 at 6:08

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .