我有一个包含大约 100,000 个文件的目录。 ls -f 挂起超过一分钟。我运行 strace,立即开始看到 getdents,所以 ls 清楚地读取了目录。我还看到很多对 brk 的调用,因此 ls 显然正在内存中缓冲内容。我编写了一个简单的程序,它调用 readdir 并输出文件名,并且它立即响应。但 ls -f 不提供输出。是什么赋予了?我认为 -f 的全部意义在于它导致 ls 除了 readdir 之外什么也不做。是否有一种可移植、可靠的方法来列出目录的内容? (注意,这是来自 Linux 上 gnu 的 coreutils 的 ls。)
-编辑-
有一个别名,但“/bin/ls -1f > /dev/null”需要8到15秒,“/bin/ls -1fx > /dev/null”需要4到11秒,但是一个简单的程序readdir 只需要 0.011 秒。我需要做什么才能让 gnu ls 不那么糟糕?
答案1
重点-f
是尝试避免需要统计每个文件条目,并避免需要在显示任何文件条目之前读取所有文件条目。它是一个“元”选项,只是禁用其他选项。
所以,是的,它应该符合您的期望。我无法回答为什么不是,但我猜测您可能有一个 shell 别名或其他可以向命令插入附加选项的东西。这可能会重新启用某个功能而不是-f
禁用该功能,并且被认为“更具体”,因此请优先考虑。
答案2
coreutils 7.0中添加了优化(commit 8d974b00fbbc2025de63e1e6d54827648fefa1c4):
2008-08-01 Kamil Dudka <[email protected]>
ls -U1 now uses constant memory
When printing one name per line and not sorting, ls now uses
constant memory per directory, no matter how many files are in
the directory.
* ls.c (print_dir): Print each file name immediately, when possible.
* NEWS: Mention the improvement.
我想到的第一个解释是您正在运行旧版本的 coreutils。你需要升级。