为什么 ls 命令在包含大量文件的 NFS 目录上中断很慢？

Question

如果我这样做，我会注意到在 NFS 上有很多文件的目录中

ls *

然后按 Ctrl-C 可能需要一段时间（比如 20 秒），然后 ls 才会回来。

为什么？可以修复 ls 命令以提高响应速度吗？

Answer 1

当您运行 时ls *，发生的第一件事是 shell 获取当前目录的列表。如果目录很大并且服务器很慢，这可能需要一段时间。

一旦 shell 获得了当前目录中文件的名称列表，它就会对该列表进行排序（与任何网络交互相比，这非常快），然后调用ls. 该ls命令依次查找每个文件并检索其元数据（stat调用）以检查其是否为目录；如果文件是目录，则ls列出其内容而不是目录本身。

当您按Ctrl+ 时C，这不会中断当前的 NFS 操作。您不能在任何地方中断文件系统操作，因为这可能会使系统处于不一致的状态。即使读取文件也可能更新其访问时间。大多数时候，按照人类标准，对文件的基本读或写操作是即时的，但 NFS 是一个例外，尤其是在慢速网络上有大量数据的情况下。

因此按下Ctrl+C只会生效：

• 如果 shell 当前正在生成文件名列表，则当该列表被完全检索时；
• 如果ls已启动并且当前正在获取有关文件的元数据，则当服务器提供元数据时；
• 如果ls已经启动并且当前正在列出一个目录，当该列表被完全检索时，或者至少在它的一个块之后。

这不是ls命令的错（甚至可能还没有启动）。这甚至不是 shell 的错：这是 NFS 的错。NFS 很慢。