filesystems – 为什么`ls –color = always`对于一个小目录来说可能会很慢？

对于我系统上的某个目录DIR,ls –color =总是大约需要8秒,尽管它包含的文件和子目录少于10个.如果没有颜色参数,它就会花费时间.

为什么我会花这么长时间用颜色参数,我怎么才能知道到底花了多长时间呢？它可能是安装在DIR中的一些子目录,但我怎样才能找出哪个是麻烦制造者？

解决方法

他们只是在我工作的服务器上禁用了颜色.根据这篇博客：
http://www.techper.net/2011/01/25/ls-command-slow-on-very-large-directories/

这可能是由于在特定目录中的所有不同坐骑上调用了stat()函数以获取颜色所呈现的信息……

这很容易证实：

time command ls /dir/with/many/toplevel/entries/ >/dev/null
time $SHELL -c "ls --color=always /dir/with/many/toplevel/entries/ >/dev/null"

对于我创建的某个有问题的目录结构,第一个命令给出：

real    0m0.523s
user    0m0.284s
sys     0m0.052s

第二个：

real    1m47.799s
user    0m0.360s
sys     0m0.928s

请记住,如果你重复底部的“基准”,它的第二次运行将有stat()数据已经在缓存中.彩色输出的第二次运行给了我：

real    0m0.409s
user    0m0.256s
sys     0m0.120s

我无法完全清除缓存以确保我可以重现“超过90秒”的结果. https://stackoverflow.com/questions/599719/how-to-clean-caches-used-by-the-linux-kernel中描述的vm.drop_caches sysctl不足.