I know that size of a directory itself is a different thing than the sizes of the files in it.

I think of a directory as a list of the directories and files within, hence a directory's size should be related to the number of files/directories within, with a minimum of 4096 bytes because of the block-size constraint.

But in my system, I have many well populated directories with 4096 bytes, and some directories which are considerably less populated that are around 10 megabytes. Can you please explain me why this happens?

  • 1
    For further reading, this is quite informative: askubuntu.com/a/404716/380067
    – kos
    Dec 26, 2015 at 10:11
  • 3
    It is not just about the number of entries in the directory but also about the length of their names.
    – kasperd
    Dec 26, 2015 at 10:52

1 Answer 1


The filesystem used, and the maximum number of entities in that directory at any point in time determines the size. Once the default size reserved for the directory is exhausted, more space is allocated for the directory. However, when the number of entities goes down, the space allocated isn't automatically freed. So, if, at one point, a directory has 10 million entities, it would remain the same size if 9,999,999 of them were deleted. This leads to interesting situations like in this Unix & Linux post.

$ mkdir foo; touch foo/{1..100000}; stat -c %s foo
$ rm foo/*; stat -c %s foo

This doesn't necessarily hold for other filesystems. The ext{2,3,4} filesystems are affected. NTFS is, to a less extent. tmpfs and btrfs aren't. ZFS is rather conservative, I got an output of 2 for the second stat command.


  • Great! I was still wondering how that could be.
    – kos
    Dec 26, 2015 at 10:08
  • XFS isnt affected! should add
    – Alex Jones
    Dec 30, 2015 at 6:59

You must log in to answer this question.

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