Is there a maximum number of inodes in a single directory?
I have a directory of over 2 million files and can't get the ls command to work against that directory. So now I'm wondering if I've exceeded a limit on inodes in Linux. Is there a limit before a 2^64 numerical limit?
df -i应该告诉您文件系统上使用和空闲的 inode 数量。
尝试ls -U或ls -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 标志也是如此。
这对于其他网络文件系统也可能是正确的。
虽然对目录中的条目数量没有强制限制，但最好对您预期的条目进行一些限制。
Can you get a real count of the number of files? Does it fall very near a 2^n boundry? Could you simply be running out of RAM to hold all the file names?
I know that in windows at least file system performance would drop dramatically as the number of files in the folder went up, but I thought that linux didn't suffer from this issue, at least if you were using a command prompt. God help you if you try to get something like nautilus to open a folder with that many files.
I'm also wondering where these files come from. Are you able to calculate file names programmatically? If that's the case, you might be able to write a small program to sort them into a number of sub-folders. Often listing the name of a specific file will grant you access where trying to look up the name will fail. For example, I have a folder in windows with about 85,000 files where this works.
If this technique is successful, you might try finding a way to make this sort permanent, even if it's just running this small program as a cron job. It'll work especially well if you can sort the files by date somewhere.
除非您收到错误消息，否则 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 脚本，将文件分成一堆目录，每个目录中的文件数量可管理。
对于 NetBackup，分析客户端中目录的二进制文件会执行某种类型的列表，该列表会因每个文件夹中的大量文件（每个文件夹大约一百万，SAP 工作目录）而超时。
我的解决方案是（正如 Charles Duffy 在此线程中所写），将文件夹重新组织在具有较少档案的子文件夹中。
另一种选择是find：
find . -name * -exec somcommands {} \;
{}是绝对文件路径。
优点/缺点是文件一个接一个地处理。
find . -name * > ls.txt
将打印所有文件名ls.txt
find . -name * -exec ls -l {} \; > ls.txt
将打印 ls 中每个文件的所有信息ls.txt