我有一个应用程序写入一个ext3目录，随着时间的推移，已经增长到大约三百万个文件。 不用说，读这个目录的文件列表是不可忍受的慢。
我不怪责ext3。 正确的解决办法是让应用程序代码写入子目录，例如./a/b/c/abc.ext而不是仅使用./abc.ext 。
我正在改变这样的子目录结构，我的问题是：大概有多less文件应该存储在一个ext3目录，同时仍然可以接受的性能？ 你有什么经验？
换句话说， 假设我需要在结构中存储300万个文件，那么./a/b/c/abc.ext结构应该有多less层次？
显然这是一个不能准确回答的问题，但我正在寻找一个球场的估计。
假如你有一个支持dir_indexfunction的发行版，那么你可以很容易地在一个目录中拥有200,000个文件。 尽pipe如此，我仍然保持在25000左右，为了安全起见。 没有dir_index ，尽量保持在5000。
非常小心如何select目录拆分。 “a / b / c”对我来说听起来像是一场灾难。
不要盲目地去做一个多目录的深层次结构，比如说第一级100个条目，第二级100个条目，第三个100个条目。 我去过那里，就这样做了，拿到了外套，并且在有几百万个文件的情况下，不得不重新调整它。 🙂
我们有一个做“多目录”布局的客户端，最终每个目录只放入一到五个文件，这就是杀了他们。 在这个目录结构中做3到6个小时做一个“du”。 这里的救星是SSD，他们不愿意重写这个应用程序的一部分，而SSD则花了数小时甚至几分钟。
问题在于，每一级目录查找都需要查找，并且查找非常昂贵。 目录的大小也是一个因素，所以它是小而不是大，是一个很大的胜利。
要回答你关于每个目录有多less个文件的问题，我听说有1000个被称为“最佳”的文件，但是10,000的性能似乎没问题。
所以，我推荐的是一级目录，每个级别都是一个长度为2个字符的目录，由大小写字母和数字组成，用于顶级目录中的大约3800个目录。 然后，您可以使用包含3800个文件的子目录来保存14M个文件，对于3M文件，每个子目录可以包含大约1,000个文件。
我已经为另一个客户做了这样的改变，这是一个巨大的变化。
我build议你用一个基准testing工具（比如邮戳）来testing各种目录大小，因为有很多像caching大小的variables（在操作系统和磁盘子系统中）取决于你的特定环境。
我的个人经验法则是瞄准目录大小<= 20k的文件，虽然我看到相对体面的性能高达10万个文件/目录。
我有所有文件去像这样的文件夹：
上传/ [date] / [小时] /yo.png
并没有任何性能问题。
http://en.wikipedia.org/wiki/Ext3#Functionality – 这提到一个目录只能有大约32000个子目录，但是没有提到文件。
http://roopindersingh.com/2008/05/10/ext3-handling-large-number-of-files-in-a-directory/
此外，我讨厌专家交stream，但我读了这个问题的意见，它是理想的，每个目录less于10-15,000。
我可以在一个相当强大的服务器上确认一个体面的负载下有足够的内存，70,000文件可以导致各种破坏。 我去了一个70k文件的caching文件夹，它导致apache开始产生新的实例，直到最大值为255，系统使用了所有的空闲内存（16GB，尽pipe虚拟实例可能已经降低了）。 无论如何，保持在25,000以下可能是一个非常谨慎的举动
根据我的经验，最好的办法是事先不要过度devise文件结构。 至less在另一个答案中提到，有文件系统扩展可以处理性能问题。
我经常碰到的问题是在行政上的可用性。 减less目录中文件数量所能做的工作量最less可能是您现在需要的方法。
sqrt（3_000_000）== 1732
在一个目录中几千个文件听起来对我来说是合理的。 做你自己的情况下自己的法官。 为了达到这个目的，可以尝试将文件拆分成一个散列目录级别，这样每个目录的平均文件数与目录数大致相同。
给你的例子，这将是./a/abc.ext ，./ ./ab/abc.ext / ./abc/abc.ext ，./ ./ab/abc.ext / ./abc/abc.ext ，…。
文件的传播很大程度上取决于实际的文件名。 想象一下，将这种技术应用到一个名为foobar???.txt的百万个文件的目录中。 有很多方法可以实现更均匀的传播，比如根据每个文件名的MD5总和中的特定位数的值进行哈希处理，但是我敢于猜测，对于您正在尝试完成的工作来说，这样做是过度的。
嗯，我最近看了这篇文章 。 本质上，你利用你最喜欢的散列algorithm的分布。 我开始玩这个数字，一个MySQL签名的INT的最大值为2147483647.你也可以改变每个目录的文件的数量和子目录的数量，以确定最终的子目录/文件数目， 每个目录分割一个给定的数据集，但很难find最佳目录/文件组织的经validation据。 本文确实介绍了跨文件系统的性能差异（一些有趣的指标），但没有提到最佳组织。
我想你对此有太多的想法了。 如果你甚至select了一个额外级别的目录，并且能够平衡一些东西，那么每个目录就有1732个*目录和1732个文件。
除非你计划需要数百亿的文件，否则你几乎可以select1000到100,000之间的数字，并获得好的结果。
* 300万的平方根。