检索非常大的目录的信息
我达到了 Linux 32,000 个子目录的限制。它导致我的 PHP 脚本出现问题，我不希望它再次发生。
简单的解决方案是让我的 PHP 脚本在尝试创建另一个子目录之前检查当前的子目录计数。
我见过的执行此类检查的所有想法都涉及迭代整个目录并计算每个文件夹。考虑到我关心的是非常大的目录，是否有更好的方法来检索它包含的文件/文件夹的数量？
额外问题：是否还有一种非迭代方法来查找目录的磁盘使用情况？
提前致谢！ 布莱恩
I hit Linux's 32,000 subdirectory limit. It caused problems with my PHP scripts and I don't want it to happen again.
The simple solution is to have my PHP scripts check the current subdirectory count before trying to create another subdirectory.
All ideas I've seen to perform such a check involve iterating over the entire directory and counting every folder. Considering my concern is with very large directories, is there a better way to retrieve the number of files/folders it contains?
Bonus question: is there also a non-iterative way to find the disk usage of a directory?
Thanks in advance!
Brian
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
更好的方法是设计目录布局，这样单个目录中就不可能有 32000 个文件。事实上，我建议即使一个目录中有 1000 个文件也太多了。
我通常采取的解决此问题的方法涉及额外级别的目录层次结构。典型的方法是获取当前存储在单个目录中的文件名，并将其分解为与嵌套目录相对应的部分。因此，如果您有一堆像这样的文件，
您实际上可能会将它们存储为
等等。您可以将其扩展到多个目录级别，或使用多个字符来分割子目录，以便权衡这种方法的深度与广度。
您可能会收到建议，建议您使用没有 32k 文件限制的文件系统。就我个人而言，即使使用这样的文件系统，我也总是会使用我在这里提出的方案。在具有大量文件的目录中几乎不可能有效地使用命令行工具（甚至 ls 也变得完全难以使用），并且在开发、调试和部署过程中始终需要这种手动探索。在正常操作期间经常会发生。
A better way is to design your directory layout so there's no way you'll ever have 32000 files in a single directory. In fact, I'd suggest that even 1000 files in a directory is too many.
The approach I usually take to this problem involves extra levels of directory hierarhy. A typical way is to take the file names you're currently storing in a single directory and break it up into pieces that correspond to nested directories. So, if you have a bunch of files like
you might in fact store them as
and so on. You can extend this to multiple directory levels, or use more than one character to split the subdirectories, in order to trade off the depth versus breadth of this approach.
You'll probably get suggestions that you use a file system that doesn't have the 32k file limit. Personally, even with such a file system, I would always use a scheme like I'm proposing here. It's almost impossible to work effectively with command-line tools in directories with very very large numbers of files (even
lsbecomes entirely unwieldy), and this sort of manual exploration is always needed during development, debugging, and often from time to time during normal operation.