3 ms·
Why does “ls” take extremely long in a small directory that used to be big?
- ggm 6y agoWhy? Because of directory block chaining, deep trees of second or third order indirect chains behind the directory, the inode cache and sparse list state after deletion. Use a tar pipe or rsync to copy subdir state in a rename/mv process to get a shorter directory inode chain and you preserve file date and timestamps. I've been able to impress people with speediest fix doing this for years. Tends to be a problem in older Fs models and I'm unsure zfs still suffers from the problem. Ext2 and UFS did until recently. Especially painful if its /tmp. It used to hit at ridiculously small file counts. 200+ was a knee in the 1980s. It's easy to get thousands of files per directory or thousands of subdirectories on a Maildir copy of an IMAP folder with 20,000 mail messages, or the like. Then delete them with a find . +mtime and you have all the old stuff gone, but the new stuff down the chain. When ls refuses to list with "too many files" i take it as a mental footnote to think about why. Not the same problem but a diagnostic symptom of the situation.