16

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)?

Community
  • 1
shearn89
  • 462
  • 1
    du tends to think differently than people, it gives a report based on some filesystem settings. you can check with '--apparent-size' here: http://www.gnu.org/software/coreutils/manual/html_node/du-invocation.html. – john-jones 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 09:39
  • @mdpc - snapshots? – shearn89 Aug 19 '13 at 09:40

2 Answers2

16

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.

user
  • 28,901
jim mcnamara
  • 745
  • 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 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 07 '17 at 03: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
0

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.

Mark C
  • 1