关于linux：目录中的inode数量最大？

一个目录中是否有最大数量的inode？

我的目录超过200万个文件，无法使用ls命令对该目录进行操作。 所以现在我想知道我是否已经超过Linux中inode的限制。 在2 ^ 64数值限制之前是否有限制？

df -i应该告诉您文件系统上已使用和可用的inode数量。

尝试ls -U或ls -f。

ls，默认情况下，按字母顺序对文件进行排序。如果您有200万个文件，则这种排序可能会花费很长时间。如果为ls -U(或者可能为ls -f)，则将立即打印文件名。

否。Inode限制是针对每个文件系统的，并在文件系统创建时决定。您可能会达到另一个极限，或者" ls"表现不佳。

尝试这个：

它应该告诉您各种与inode相关的信息。

您命中的是内部限制ls。 这是一篇很好解释的文章：
http://www.olark.com/spw/2011/08/you-can-list-a-directory-with-8-million-files-but-not-with-ls/

最大目录大小取决于文件系统，因此确切的限制有所不同。但是，拥有非常大的目录是一种不好的做法。

您应该考虑通过将文件分类到子目录中来缩小目录。一种常见的方案是将前两个字符用于一级子目录，如下所示：

如果使用UUID，GUID或内容哈希值进行命名，则效果特别好。

正如Rob Adams指出的那样，ls在显示文件之前先对其进行排序。请注意，如果您使用的是NFS，则NFS服务器将在发送目录之前对其进行排序，而200万个条目的花费可能比NFS超时花费的时间更长。即使使用-f标志，该目录也无法通过NFS列出。

其他网络文件系统也可能如此。

尽管目录中的条目数没有强制限制，但是最好对预期的条目进行一些限制。

对于NetBackup，在客户端中分析目录的二进制文件执行某种类型的列表，该列表由于每个文件夹中的大量文件(每个文件夹大约一百万，SAP工作目录)而超时。

我的解决方案是(如Charles Duffy在此线程中所写)，用更少的归档重组子文件夹中的文件夹。

除非收到错误消息，否则ls会运行，但运行速度非常缓慢。您可以尝试仅查看前十个文件，如下所示：

ls -f | head -10

如果您需要一段时间查看文件详细信息，可以先将它们放在文件中。您可能希望将输出发送到与您当前列出的目录不同的目录！

ls > ~/lots-of-files.txt

如果要对文件做一些操作，可以使用xargs。如果决定编写某种脚本来完成工作，请确保脚本将文件列表作为流而不是一次全部处理。这是移动所有文件的示例。

ls | xargs -I thefilename mv thefilename ~/some/other/directory

您可以将其与head结合使用，以移动较少数量的文件。

ls | head -10000 | xargs -I x mv x /first/ten/thousand/files/go/here

您可能可以将ls | head组合到一个shell脚本中，该脚本会将文件拆分成一堆目录，每个目录中的文件数量都可以控制。

您能否获得文件数量的真实计数？它是否非常接近2 ^ n边界？您可以简单地用完RAM来保存所有文件名吗？

我知道在Windows中，至少随着文件夹中文件数量的增加，文件系统的性能将急剧下降，但是我认为linux不会受到此问题的影响，至少在使用命令提示符的情况下。如果您尝试让鹦鹉螺之类的东西打开包含那么多文件的文件夹，上帝会帮助您。

我也想知道这些文件来自哪里。您可以通过编程方式计算文件名吗？如果是这样，您也许可以编写一个小程序将它们分类为多个子文件夹。通常，列出特定文件的名称将使您可以访问尝试查找该名称失败的位置。例如，我在Windows上有一个包含约85,000个文件的文件夹，可以在其中运行。

如果这项技术成功，那么即使它只是作为cron作业运行这个小程序，您也可以尝试找到一种使这种永久化的方法。如果您可以按日期对文件进行排序，它将特别有效。

另一个选项是find：

find . -name * -exec somcommands {} \;

{}是绝对文件路径。

优点/缺点是文件被一个接一个地处理。

find . -name * > ls.txt

将打印ls.txt中的所有文件名

find . -name * -exec ls -l {} \; > ls.txt

将为ls.txt中的每个文件打印所有信息形式ls