我们有一个使用Jira的系统，Jira在/opt/jira/jiraattachments存储附件。 在该目录下是项目名称RRT ，在该目录下是票据目录。 因此，票RRT1234有其附件：
/opt/jira/jiraattachments/RRT/RRT1234
我们有一个监控系统，当/opt/jira/jiraattachments/RRT目录中有超过30,000个项目时，会触发警报。 考虑到我们有90万吉拉门票，这不是一个真正的惊喜。
在编程层面上，我真的没有看到一个问题。 Jira不打开整个目录并保持所有这些目录的打开。 实际上，这个结构是安排好的，这样Jira可以立即find包含附件的目录。
但是，在操作系统级别，包含超过32K文件的单个目录是否存在问题？ 我可以看到编写shell脚本的问题，并尝试parsing这些文件。 我可以看到ls试图读取和sorting所有这些文件的问题。 我知道回到MS-DOS 2.x天，一个目录不能超过512个条目。 但是我们已经不在迪斯科时代了。 我不能看到一个操作系统绊倒这样的事情。
$ uname -r 2.6.18-238.el5 $ df -kT . Filesystem Type 1K-blocks Used Available Use% Mounted on 10.10.136.125:/vol/jira_prod nfs 83886080 58621352 25264728 70% /jira_prod
我不能完全解释他们的基本原理，但可以说ext3有32000个子目录限制 。 它可以很容易地容纳一个目录中的1 / 4M文件，更取决于您的服务器。 按照方向清单/sorting显然是昂贵的，但是即使知道文件名（索引可以提高性能，但并不能解决所有问题），也没有任何机制可以避免更高的查找“成本”。
正如你所期望的那样，性能处罚会随着规模变得更糟。 大多数build议是保持每个目录less于15-25k的文件。 如果你没有看到任何性能问题，我不会担心。 文件系统不会崩溃，对于每个添加的文件来说只会变慢。