How come "ls -U" on a directory that contains many files takes some time, while doing "ls -U | head" returns an answer immediately?

cn flag

When you want to get a sample of file names from a directory that contains many files, it is advised to do "ls -U | head", because otherwise doing "ls" alone can take quite some time.

However, why doesn't "ls -U" by it self does not start returning outputs as soon as it ran?

cn flag

GNU ls -U means unsorted output, so it does not need to wait for all the directory contents to start printing them.

head will close stdin and quit after a small number of lines. When the writer to the pipe, ls in this case, has no more readers, it will quit. This will flush all the I/O involved after only a small number of lines, making it seem snappy in interactive use.

Further reading: Process not closing when stdin is closed

A noticeable to humans delay in listing directory contents is a sign of exceeding practical limits. Lots of files in a directory means large file system metadata, and so a lot of I/O. Lots typically means hundreds of thousands of files, even for production tested file systems.

Beyond a certain number of files, it makes sense to reconsider alterative directory layouts and databases. Short term, put the problem volume on fast SSDs to make its performance tolerable.


Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.