快速 ls 命令

Question

我必须获得包含大约 200 万个文件的目录列表，但是当我对其执行 ls 命令时，什么也没有返回。 我已经等了3个小时了 我已经尝试过 ls | tee directory.txt，但这似乎永远挂起。

我假设服务器正在执行大量索引节点排序。 有没有什么方法可以加快 ls 命令的速度以获取文件名的目录列表？ 我现在不关心大小、日期、许可等。

Answer 1

这可能不是一个有用的答案，但如果您没有 find，您也许可以使用 tar

$ tar cvf /dev/null .

比我年长的人告诉我，“在过去，单用户和恢复环境比现在要有限得多。 这就是这个技巧的由来。

Answer 2

我假设你正在使用 GNU ls？
尝试

\ls

它将取消通常的 ls (ls --color=auto) 的别名。

Answer 3

要尝试的事情：

检查 ls 是否有别名？

alias ls

也许尝试查找？

find . \( -type d -name . -prune \) -o \( -type f -print \)

希望这可以帮助。

Answer 4

一些后续行动：
您没有提及您正在运行的操作系统，这将有助于表明您正在使用哪个版本的 ls 。 这可能不是一个“bash”问题，而是一个 ls 问题。 我的猜测是你正在使用 GNU ls，它有一些在某些情况下有用的功能，但在大目录上会杀掉你。

GNU ls 试图对列进行更漂亮的排列。 GNU ls 尝试对所有文件名进行智能排列。 在一个巨大的目录中，这将需要一些时间和内存。

要“修复”此问题，您可以尝试：

ls -1 # no columns at all

find BSD ls someplace, http://www.freebsd.org/cgi/cvsweb.cgi/src/bin/ls/ 并使用在你的大目录上。

使用其他工具，例如 find

Answer 5

有多种方法可以获取文件列表：

使用此命令获取不排序的列表：

ls -U

或使用以下命令将文件列表发送到文件：

ls /Folder/path > ~/Desktop/List.txt

Answer 6

您使用什么分区类型？

如果一个目录中有数百万个小文件，那么使用 JFS 或 ReiserFS 可能是一个好主意，它们对于许多小文件具有更好的性能。

Answer 7

find ./ -type f 怎么样（它将查找当前目录中的所有文件）？ 取消-type f即可找到所有内容。

Answer 8

您应该提供有关您正在使用的操作系统和文件系统类型的信息。 在某些风格的 UNIX 和某些文件系统上，您可能可以使用命令 ff 和 ncheck 作为替代方案。

Answer 9

我有一个文件名中带有时间戳的目录。 我想检查最新文件的日期并找到 find 。 -类型 f -最大深度 1 | 排序| tail -n 1 的速度大约是 ls -alh 的两倍。

Answer 10

这里还有很多其他好的解决方案，但为了完整性：

echo *

Answer 11

您还可以使用 xargs。 只需通过 xargs 传输 ls 的输出即可。

ls | xargs

如果这不起作用并且上面的 find 示例不起作用，请尝试将它们通过管道传输到 xargs，因为它可以帮助减少可能导致问题的内存使用情况。

Answer 12

如果进程“没有回来”，我建议 strace 来分析进程如何进程正在与操作系统交互。

如果是 ls：

$strace ls

您会看到它读取所有目录条目 (getdents(2)) 在它实际输出任何内容之前。 （排序……因为这里已经提到了）

Answer 13

使用速度

ls -1 -f 

大约快 10 倍，而且很容易做到（我测试了 100 万个文件，但我最初的问题有 6 800 000 000 个文件），

但就我而言，我需要检查某个特定目录是否包含超过 10 000 个文件。 如果有超过 10 000 个文件，我不再对有多少文件感兴趣。 我只是退出程序，以便它运行得更快，并且不会尝试一一阅读其余部分。 如果少于 10 000，我会打印确切的数量。 如果您指定的参数值大于文件数量，我的程序的速度与 ls -1 -f 非常相似。

您可以通过键入以下内容在当前目录中使用我的程序 find_if_more.pl：

find_if_more.pl 999999999

如果您只对是否有超过 n 个文件感兴趣，则对于大量文件，脚本将比 ls -1 -f 更快完成。

#!/usr/bin/perl
    use warnings;
    my ($maxcount) = @ARGV;
    my $dir = '.';
    $filecount = 0;
    if (not defined $maxcount) {
      die "Need maxcount\n";
    }
    opendir(DIR, $dir) or die $!;
    while (my $file = readdir(DIR)) {
        $filecount = $filecount + 1;
        last if $filecount> $maxcount
    }
    print $filecount;
    closedir(DIR);
    exit 0;

Answer 14

据我所知，这将是最快的选项：ls -1 -f。

• -1（无列）
• -f（无排序）

Answer 15

您可以重定向输出并在后台运行 ls 进程。

ls > myls.txt &

这将使您能够在业务运行的同时继续开展业务。 它不会锁定你的外壳。

不确定运行 ls 并获取更少数据的选项是什么。 您始终可以运行 man ls 进行检查。

Answer 16

尝试使用：

find . -type f -maxdepth 1

这只会列出目录中的文件，如果您想列出文件和目录，请省略 -type f 参数。

Answer 17

我有一个包含 400 万个文件的目录，让 ls 立即吐出文件而无需首先进行大量搅动的唯一方法是

ls -1U

Answer 18

ls -U

将执行 ls 而不排序。

缓慢的另一个来源是--color。 在某些 Linux 机器上，有一个方便的别名，它将 --color=auto' 添加到 ls 调用中，使其查找找到的每个文件的文件属性（缓慢），以对显示进行着色。 这可以通过 ls -U --color=never 或 \ls -U 来避免。

Answer 19

这个问题似乎很有趣，我正在查看发布的多个答案。 为了了解发布的答案的效率，我在 200 万个文件上执行了它们，发现结果如下。

$ time tar cvf /dev/null . &> /tmp/file-count

real    37m16.553s
user    0m11.525s
sys     0m41.291s

------------------------------------------------------

$ time echo ./* &> /tmp/file-count

real    0m50.808s
user    0m49.291s
sys     0m1.404s

------------------------------------------------------

$ time ls &> /tmp/file-count

real    0m42.167s
user    0m40.323s
sys     0m1.648s

------------------------------------------------------

$ time find . &> /tmp/file-count

real    0m2.738s
user    0m1.044s
sys     0m1.684s

------------------------------------------------------

$ time ls -U &> /tmp/file-count

real    0m2.494s
user    0m0.848s
sys     0m1.452s


------------------------------------------------------

$ time ls -f &> /tmp/file-count

real    0m2.313s
user    0m0.856s
sys     0m1.448s

------------------------------------------------------

总结一下结果，

1. ls -f 命令的运行速度比 ls -U 快一些。 禁用颜色可能会导致这种改进。
2. find 命令以 2.738 秒的平均速度排名第三。
3. 仅运行 ls 就花费了 42.16 秒。 在我的系统中，ls 是 ls --color=auto 的别名，
4. 使用带有 echo ./* 的 shell 扩展功能运行了 50.80 秒。
5. 基于 tar 的解决方案花费了大约 37 分钟。

所有测试均在系统空闲状态下单独进行。

这里需要注意的一件重要事情是文件列表不会打印在终端中，而是打印在终端中。
它们被重定向到一个文件，稍后使用 wc 命令计算文件计数。
如果输出打印在屏幕上，则命令运行速度太慢。

有什么想法为什么会发生这种情况吗？