On my mac I did find ~/ in the terminal to list all the files in my home directory it listed over 500,000. This seems like an awful lot to me and occasionally my computer is slow. Is there any recommended maximum number of files to have? Even though a lot of the files are little would they cause the file system index to get really large and unwieldy?
2 Answers
As pointed out in a comment, you're using a command that is locating files within directories below the directory in question. While you may only be able to count to about 20 (fingers and toes) OS's are much much better at dealing with large numbers of files, and this is really an issue you shouldn't worry about.
Now if your computer is slow, you might want to look into what is using memory.
-
I disagree. Depending on the filesystem in use, any structure that bursts beyond the seams of cache structures or other fs-inherent optimizations can be penalized pretty badly. A frequently seen example would be a directory containing files following the popular pattern filename-date-time. While pleasant to human readers and sorting neatly, it's a pain to lookup, since it has to read and compare all those meaningless identical "filename" bits before hitting the part that matters. If in addition the directory is too large to fit into the cache, that process has to be repeated at every access... Commented Jun 17, 2019 at 17:25
-
1@TatjanaHeuser The problem you mention is real for sure, but constrained to some very specific use cases. I just counted the files/folders in my
$HOME: there are 1'340'000 files within 400'000 folders, so basically three files per folder. Of course there will be borderline cases, but scanning through hundreds of similarly named files will be very rare. It does at least not explain a general slowdown during everyday use.– nohillside ♦Commented Jun 17, 2019 at 17:58 -
1@nohillside "three files per folder" won't burst your directory lookup cache. 500000 files named scan0000001.tiff - scan5000000.tiff will, though. If these files are created by a script, it's easy to overlook the problems arising from that kind of organization scheme. Commented Jun 17, 2019 at 18:06
If a directory grows larger than the directory cache, access to it would indeed be slowed down significantly. A users home directory is one of the directories that gets traversed often, especially since many programs started by and for the user start with it as their working directory.
This definitely is a reason to keep the home directory itself organized, and shift clutter into subdirectories.
As Ian pointed out in his comment, your home directory may be perfectly organized though - all you have been looking at is the collated number of files and directories contained within the structure of your home directory, no matter how deep.
To find out how many entries your home directory is containing directly, you can use find restricted by depth:
find $HOME -depth 1 |wc -l
To anyone wanting to circumvent the snags of a less-than-optimal directory structure, the 2015 article by Tsai et al., How to get more value from your file system directory cache would probably be one of the easier introductions to the subject.
-
It might not be accurate case of your reasoning but I had some datasets. You can imagine the level of naming structure. So deleting thousands of files is slower than a single file of the same size.– ankiCommented Jun 17, 2019 at 17:29
find ~/finds all the files in and below your home directory, they're not all directly in you're home directory, their in your home directory tree hierarchy.