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. – Hermann Ingjaldsson Aug 16 '13 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 Aug 16 '13 at 12:21
  • Have you accounted for the snapshots? – mdpc Aug 16 '13 at 16:10
  • @slm - they come out at the normal 4096 (bytes?) size. – shearn89 Aug 19 '13 at 9:39
  • @mdpc - snapshots? – shearn89 Aug 19 '13 at 9:40

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. – Patrick Aug 16 '13 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. – jim mcnamara Aug 16 '13 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. – Sean McSomething Aug 16 '13 at 21:43
  • @SeanMcSomething What problems do you mean? – Hatshepsut Sep 7 '17 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 Feb 27 '18 at 23:44

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.