When running ls -l, why does the filesize on a directory not match the output of du?

Question

What does 4096 mean in output of ls -l?

[root@file nutch-0.9]# du -csh resume.new/
2.3G    resume.new/
[root@file nutch-0.9]# ls -l 
total 55132
drwxr-xr-x  7 root root     4096 Jun 18 03:19 resume.new

Answer 1

That the directory takes up 4096 bytes of disk space (not including its contents).

Answer 2

I have been wondering about it too. So, after searching I came across:

"It's the size necessary to store the meta-data about files (including the file names contained in that directory). The number of files / sub-directories at a given time might not map directly to the size reported, because once allocated, space is not freed if the number of files changes. This behaviour makes sense for most use cases (where disk space is cheap, and once a directory has a lot of files in it, it will probably have them again in future), and helps to reduce fragmentation."

Reference: http://www.linuxquestions.org/questions/showthread.php?p=2978839#post2978839

Answer 3

Directories are just like files with <name, inode> tuples, and that are specially treated by the filesystem. The size reported by ls is the size of this "file". Check this answer in Server Fault for an overview of how directories are under the hood.

So, the 4096 bytes mean, most likely, that the filesystem block size is 4096 and that directory is currently using a single block to store this table of names and inodes.

Answer 4

4096, in your example, is the number of bytes used by the directory itself. In other words, this is the space required to store the list of items contained in the directory. It is not, as the question title suggests, the sum of the space of all of the items stored in the directory.

You don't say what system you're using, but in many UNIX/Linux file systems, the minimum unit of storage allocation is 4K, which is why the size is showing as 4096. The directory entries for two items, plus "." and "..", should take considerably less space.