目录中的最大数量的inode?

单个目录中是否有最大数量的inode?

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

df -i应该告诉你在文件系统上使用和释放的inode的数量。

试试ls -Uls -f

默认情况下, ls按字母顺序对文件进行排序。 如果您有200万个文件,那么这种排序可能需要很长时间。 如果ls -U (或者ls -f ),那么文件名将被立即打印。

不.Inode限制是每个文件系统,并决定在文件系统创建时间。 你可能会遇到另一个限制,或者'ls'可能表现不佳。

尝试这个:

 tune2fs -l /dev/DEVICE | grep -i inode 

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

你碰到的是ls的内部限制。 这里有一篇文章对此进行了很好的解释: http : //www.olark.com/spw/2011/08/you-can-list-a-directory-with-8-million-files-but-not-with- LS /

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

您应该考虑通过将文件分类到子目录来缩小目录。 一个常见的方案是使用前两个字符作为第一级子目录,如下所示:

 $ {} TOPDIR / AA /食蚁兽
 $ {TOPDIR} / AI /飞机

如果使用UUID,GUID或内容哈希值进行命名,此功能特别有效。

正如Rob Adams所指出的那样,ls在显示文件之前对文件进行排序。 请注意,如果您使用的是NFS,那么NFS服务器将在发送目录之前对其进行排序,并且200万个条目可能需要比NFS超时更长的时间。 这使得目录无法通过NFS登录,即使使用了-f标志。

对于其他网络文件系统也是如此。

尽管对目录中条目的数量没有强制限制,但对于您预期的条目有一些限制是很好的做法。

你能得到一个真正的文件数量? 它是否非常接近2 ^ n边界? 你可以简单地用完内存来保存所有的文件名吗?

我知道,在Windows中至少文件系统的性能会随着文件夹中文件数量的增加而急剧下降,但我认为linux并没有遭受这个问题,至少如果你使用的是命令提示符。 上帝帮助你,如果你试图得到像鹦鹉螺一样打开一个文件夹与许多文件。

我也想知道这些文件来自哪里。 你能够以编程方式计算文件名吗? 如果是这样的话,你也许可以编写一个小程序,将它们分类成多个子文件夹。 通常列出特定文件的名称将授予您访问的地方,试图查找名称将失败。 例如,我有一个文件夹在Windows中与大约85,000个文件,这工作。

如果这个技巧成功,你可能会尝试找到一种永久性的方法,即使它只是把这个小程序作为一个cron工作来运行。 如果你可以在某个地方按日期对文件进行排序,那么它将工作得特别好。

除非您收到错误消息,否则ls正在运行,但速度很慢。 你可以试试看这样的前十个文件:

ls -f | head -10

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

ls > ~/lots-of-files.txt

如果你想对文件做些什么,你可以使用xargs。 如果您决定编写某种脚本来完成这项工作,请确保您的脚本将流式处理文件列表,而不是一次处理所有文件。 这是一个移动所有文件的例子。

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

您可以将其与头部结合,以移动较少数量的文件。

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

你大概可以把ls | head结合起来 进入一个shell脚本,将文件分割成一堆目录,每个目录都有可管理数量的文件。

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

我的解决方案是(正如Charles Duffy在此线程中所写),使用较少的存档重新组织子文件夹中的文件夹。

另一种选择是find

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

{}是绝对文件路径。

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

find . -name * > ls.txt

将在ls.txt打印所有文件名

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

将在ls.txt打印每个文件的所有信息