1

In trying to verify that a copy-operation completed successfully (or at least that it didn't skip any files), I ran du -b inside the source and destination directory and it showed a difference of about 100KB.

So, I went tracking down the difference and found one (of many) leaf-directory where du reports a difference in total size for the copy and the original.

The strange thing is that ls -l shows these directories as perfectly identical!

Here are the two outputs in the two different directories:

root@...:/local/.../DCIM/100___12# du -b
5286222389      .
root@...:/local/.../DCIM/100___12# ls -l --block-size=1
total 5292851200
-rwxr--r-- 1 markus markus   2167504 Aug  5  2013 IMG_0004.JPG
-rwxr--r-- 1 markus markus   2236594 Aug  5  2013 IMG_0005.JPG
...

vs.

root@...:/local_old/.../DCIM/100___12# du -b
5286226485      .
root@...:/local_old/.../DCIM/100___12# ls -l --block-size=1
total 5292851200
-rwxr--r-- 1 markus markus   2167504 Aug  5  2013 IMG_0004.JPG
-rwxr--r-- 1 markus markus   2236594 Aug  5  2013 IMG_0005.JPG
...

Note how the size reported by du -b is less than that reported by ls -l and that it differs for the two directories. The entire output of ls -l is identical for both directories.

There are no symlinks or system files in this directory. It's just a bunch of .jpg files (a direct copy off a camera's SD-card) and a Thumbs.db-file that Windows created for them (via samba)...

Am I missing something about how these commands should work?

(I'm running Debian Wheezy and uname -a outputs Linux ... 3.2.0-4-amd64 #1 SMP Debian 3.2.63-2+deb7u1 x86_64 GNU/Linux)

3

Both are right.

  • ls shows the exact bytes of the files
  • du is showing the disk usage, that is different because the system store the files using blocks.

You can find the block size your file system is using with this command:

blockdev --getbsz <partition>

For example:

blockdev --getbsz /dev/sda1
| improve this answer | |
  • I thought that the -b switch for du (which implies --apparent-size) changes that. Also, if that was the issue, the output of du should be more than that of ls, rather than less, no? And the blocksize on both, the source and target directory, is the same. – Markus A. Dec 17 '14 at 9:27
  • blockdev reports the device's block size, which is not the same as a filesystem's cluster/sector size. For example, it's very common to use 4k or 8k clusters on a 512b disk. – user1686 Dec 17 '14 at 9:33
  • I don't know exactly why du show less than ls unless you have sparse files – jcbermu Dec 17 '14 at 10:04
0

After adding the -a switch to ls, I got:

root@...:/local/.../DCIM/100___12# du -b
5286222389      .
root@...:/local/.../DCIM/100___12# ls -al --block-size=1
total 5292867584
drwxr-xr-x 2 markus markus     12288 Aug  5  2013 .
drwxr-xr-x 4 markus markus      4096 Aug  5  2013 ..
-rwxr--r-- 1 markus markus   2167504 Aug  5  2013 IMG_0004.JPG
...

vs.

root@...:/local_old/.../DCIM/100___12# du -b
5286226485      .
root@...:/local_old/.../DCIM/100___12# ls -als --block-size=1
total 5292871680
drwxr-xr-x 2 markus markus     16384 Aug  5  2013 .
drwxr-xr-x 4 markus markus      4096 Aug  5  2013 ..
-rwxr--r-- 1 markus markus   2167504 Aug  5  2013 IMG_0004.JPG
...

Notice the difference in the size of the .-directory, which makes up exactly for the difference reported by du -b.

Also, it seems that the total reported by ls is actually in blocks rather than bytes. So the answer is sort-of what @jcbermu suggested, but backwards:

Yes, both are right, but ls reports the total size in used fs-blocks (but individual file sizes in bytes) and du -b reports bytes.

The difference between the source and destination that I'm seeing is caused by a difference in the size reported for .. Where this comes from, is another story. Probably because one reserved more directory entries at some point than the other. But at least now I'm not worried any more that something got missed in the copy process. Next step is to figure out how to tell du to ignore . and .. in its totals and that should resolve my problem.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.