Linux 目录中的最大索引节点数？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/40368/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Maximum number of inodes in a directory?
提问by Mark Witczak
Is there a maximum number of inodes in a single directory?
单个目录中是否有最大数量的 inode？
I have a directory of over 2 million files and can't get the lscommand 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?
我有一个包含超过 200 万个文件的目录，但无法获得ls针对该目录工作的命令。所以现在我想知道我是否超过了 Linux 中 inode 的限制。在 2^64 数字限制之前是否有限制？
回答by Joel Coehoorn
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?
你能得到文件数量的真实计数吗？它是否非常接近 2^n 边界？您是否可能只是因为内存不足而无法保存所有文件名？
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.
我知道在 Windows 中，至少文件系统的性能会随着文件夹中文件数量的增加而急剧下降，但我认为 linux 不会遇到这个问题，至少在您使用命令提示符的情况下。如果您尝试使用 nautilus 之类的工具打开包含这么多文件的文件夹，上帝会帮助您。
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.
我也想知道这些文件是从哪里来的。你能以编程方式计算文件名吗？如果是这种情况，您也许可以编写一个小程序将它们分类到多个子文件夹中。通常列出特定文件的名称将授予您访问权限，而尝试查找名称将失败。例如，我在 Windows 中有一个文件夹，其中包含大约 85,000 个文件，可以在其中工作。
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.
如果此技术成功，您可能会尝试找到一种方法使这种排序永久化，即使它只是将这个小程序作为 cron 作业运行。如果您可以在某处按日期对文件进行排序，它将特别有效。
回答by Jordi Bunster
No. Inode limits are per-filesystem, and decided at filesystem creation time. You could be hitting another limit, or maybe 'ls' just doesn't perform that well.
不可以。inode 限制是针对每个文件系统的，并在文件系统创建时决定。您可能会遇到另一个限制，或者 'ls' 可能表现不佳。
Try this:
尝试这个：
tune2fs -l /dev/DEVICE | grep -i inode
It should tell you all sorts of inode related info.
它应该告诉你各种与 inode 相关的信息。
回答by Joseph Bui
Unless you are getting an error message, ls is working but very slowly. You can try looking at just the first ten files like this:
除非您收到错误消息，否则 ls 正在运行，但速度非常慢。您可以尝试只查看前十个文件，如下所示：
ls -f | head -10
ls -f | head -10
If you're going to need to look at the file details for a while, you can put them in a file first. You probably want to send the output to a different directory than the one you are listing at the moment!
如果您需要暂时查看文件详细信息，可以先将它们放入一个文件中。您可能希望将输出发送到与您目前列出的目录不同的目录！
ls > ~/lots-of-files.txt
ls > ~/lots-of-files.txt
If you want to do something to the files, you can use xargs. If you decide to write a script of some kind to do the work, make sure that your script will process the list of files as a stream rather than all at once. Here's an example of moving all the files.
如果你想对文件做一些事情，你可以使用 xargs。如果您决定编写某种脚本来完成这项工作，请确保您的脚本将文件列表作为流而不是一次性全部处理。这是移动所有文件的示例。
ls | xargs -I thefilename mv thefilename ~/some/other/directory
ls | xargs -I thefilename mv thefilename ~/some/other/directory
You could combine that with head to move a smaller number of the files.
您可以将其与 head 结合使用以移动较少数量的文件。
ls | head -10000 | xargs -I x mv x /first/ten/thousand/files/go/here
ls | head -10000 | xargs -I x mv x /first/ten/thousand/files/go/here
You can probably combine ls | headinto a shell script to that will split up the files into a bunch of directories with a manageable number of files in each.
您可能可以组合ls | head成一个 shell 脚本，以便将文件拆分为一堆目录，每个目录中包含可管理数量的文件。
回答by tonylo
df -ishould tell you the number of inodes used and free on the file system.
df -i应该告诉您文件系统上已使用和空闲的 inode 数。
回答by Rob?
Try ls -Uor ls -f.
尝试ls -U或ls -f。
ls, by default, sorts the files alphabetically. If you have 2 million files, that sort can take a long time. If ls -U(or perhaps ls -f), then the file names will be printed immediately.
ls，默认情况下，按字母顺序对文件进行排序。如果您有 200 万个文件，那么排序可能需要很长时间。如果ls -U（或可能ls -f），则将立即打印文件名。
回答by Charles Duffy
Maximum directory size is filesystem-dependent, and thus the exact limit varies. However, having very large directories is a bad practice.
最大目录大小取决于文件系统，因此确切的限制会有所不同。但是，拥有非常大的目录是一种不好的做法。
You should consider making your directories smaller by sorting files into subdirectories. One common scheme is to use the first two characters for a first-level subdirectory, as follows:
您应该考虑通过将文件分类到子目录来缩小目录。一种常见的方案是将前两个字符用于一级子目录，如下所示：
${topdir}/aa/aardvark
${topdir}/ai/airplane
This works particularly well if using UUID, GUIDs or content hash values for naming.
如果使用 UUID、GUID 或内容哈希值进行命名，这会特别有效。
回答by mpez0
As noted by Rob Adams, ls is sorting the files before displaying them. Note that if you are using NFS, the NFS server will be sorting the directory before sending it, and 2 million entries may well take longer than the NFS timeout. That makes the directory unlistable via NFS, even with the -f flag.
正如 Rob Adams 所指出的， ls 在显示文件之前对文件进行排序。请注意，如果您使用 NFS，NFS 服务器将在发送之前对目录进行排序，并且 200 万个条目可能比 NFS 超时花费更长的时间。这使得目录无法通过 NFS 列出，即使使用 -f 标志也是如此。
This may be true for other network file systems as well.
对于其他网络文件系统也可能如此。
While there's no enforced limit to the number of entries in a directory, it's good practice to have some limit to the entries you anticipate.
虽然对目录中的条目数量没有强制限制，但对您预期的条目进行一些限制是一种很好的做法。
回答by mario
For NetBackup, the binaries that analyze the directories in clients perform some type of listing that timeouts by the enormous quantity of files in every folder (about one million per folder, SAP work directory).
对于 NetBackup，分析客户端目录的二进制文件会执行某种类型的列表，这些列表会因每个文件夹中的大量文件（每个文件夹约一百万，SAP 工作目录）而超时。
My solution was (as Charles Duffy write in this thread), reorganize the folders in subfolders with less archives.
我的解决方案是（正如 Charles Duffy 在此线程中所写的那样），重新组织子文件夹中的文件夹，并且档案较少。
回答by markus
Another option is find:
另一种选择是find：
find . -name * -exec somcommands {} \;
find . -name * -exec somcommands {} \;
{}is the absolute filepath.
{}是绝对文件路径。
The advantage/disadvantage is that the files are processed one after each other.
优点/缺点是文件一个接一个地处理。
find . -name * > ls.txt
find . -name * > ls.txt
would print all filenames in ls.txt
将打印所有文件名 ls.txt
find . -name * -exec ls -l {} \; > ls.txt
find . -name * -exec ls -l {} \; > ls.txt
would print all information form ls for each file in ls.txt
将打印每个文件的所有信息表单 ls ls.txt
回答by DragonTux
What you hit is an internal limit of ls. Here is an article which explains it quite well: http://www.olark.com/spw/2011/08/you-can-list-a-directory-with-8-million-files-but-not-with-ls/
你击中的是 ls 的内部限制。这是一篇很好地解释它的文章：http: //www.olark.com/spw/2011/08/you-can-list-a-directory-with-8-million-files-but-not-with- ls/
