I've just read this question: What does size of a directory mean in output of 'ls -l' command?

...which doesn't quite answer my question. Basically, I'm moving files onto a NAS. The folders I've already moved are completely empty, with no hidden files or anything, and yet du still reports their size at 3.5MB. Admittedly, they previously contained a large number of files, with long filenames.

Is this size simply because of the quantity and name-length of files that were in that directory? Why hasn't the size decreased now that the folders are empty (ext4 filesystem)?

  • 1
    du tends to think differently than people, it gives a report based on some filesystem settings. you can check with '--apparent-size' here: gnu.org/software/coreutils/manual/html_node/du-invocation.html.
    – john-jones
    Commented Aug 16, 2013 at 12:01
  • When you copy newly created empty directories to the NAS what do those report their sizes to be? Also do you have access to the NAS where you could run tune2fs, for example?
    – slm
    Commented Aug 16, 2013 at 12:21
  • Have you accounted for the snapshots?
    – mdpc
    Commented Aug 16, 2013 at 16:10
  • @slm - they come out at the normal 4096 (bytes?) size.
    – shearn89
    Commented Aug 19, 2013 at 9:39
  • @mdpc - snapshots?
    – shearn89
    Commented Aug 19, 2013 at 9:40

2 Answers 2


When you delete all the files from a directory, for most file systems, the directory remains the same size.

If the directory is empty,

rmdir ./directory_name; mkdir ./directory

The resulting new directory will be smaller. But as files are added it will grow larger. Do not worry about directory file size as much as the number of files in a single directory. Huge numbers of files in a single directory impact file lookup performance negatively. Even with ample inode caching.

  • 4
    The large number of files in 1 directory really only matters for ext filesystems. Others like xfs, btrfs, reiser, etc don't have the same issue.
    – phemmer
    Commented Aug 16, 2013 at 12:36
  • 2
    That is correct. However ufs does have the problem as do others. While this question is strictly ext4, the problem is ubiquitous so I mentioned it. Commented Aug 16, 2013 at 15:58
  • Aside from performance issues, putting too many files in a directory can cause other problems - doing an rm * could result in problems if you have more than 1024 files. Commented Aug 16, 2013 at 21:43
  • @SeanMcSomething What problems do you mean?
    – Hatshepsut
    Commented Sep 7, 2017 at 3:15
  • 1
    @SeanMcSomething I have no idea, from where did you get this crap. The command line of a process can be a half megabyte or more. It has nothing to do with the count of the files, the total size of the command line has a limit, which is much higher as you say.
    – peterh
    Commented Feb 27, 2018 at 23:44

In Solaris, it makes a difference in ufs on how many files are in a directory before it impacts performance. I've found on several systems where a directory will have 100s of thousands of tiny files. The size of the directory isn't that great but the number of files makes it impossible to do anything in the directory. You cannot just rm * the files as it will cause the system to lock up. The only way to remove them I've found is to generate a list (ls the-directory >> file.list) and then a short one line script of for-do-done and remove them one by one. It takes a long time but is the only way to remove them without locking up the system. After the directory is empty, if it is still needed, remove and recreate the directory so the listed block size is commensurate to what is in it. Later, if this is some sort of system management directory (like in /var) have a daily cron job to trim it and keep it a manageable number of files.

You must log in to answer this question.

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