我正在写一个应用程序在ext3文件系统上存储大量的图像（大小<5MB），这是我现在所拥有的。 在这里searchserverfault后，我已经决定了这样的目录结构：
000/000/000000001.jpg ... 236/519/236519107.jpg 这个结构将允许我保存多达1,000,000,000个图像，因为我将在每一片叶子中存储最多1000个图像。
我已经创build了它，从理论的angular度来看似乎对我来说还是可以的（尽pipe我没有这方面的经验），但是我想知道在那里会有充满文件的目录时会发生什么。
关于创build这个结构的问题：最好是一次性创build它（我的电脑需要大约50分钟），还是应该根据需要创build目录？ 从开发人员的angular度来看，我认为第一个select是更好的（没有额外的用户等待时间），但从系统pipe理员的angular度来看，这是好的吗？
我以为我可以做，就好像文件系统已经在正在运行的应用程序，我会做一个脚本，将尽可能快地保存图像，监测事情如下：
是否启动此命令
sync; echo 3 | sudo tee /proc/sys/vm/drop_caches
有什么意义呢？ 如果我想重新开始我的testing，这是我必须做的唯一一个干净的开始？
你有什么build议或更正？
编辑：我做了文件系统的select，反对数据库，因为这两个问题：
Pehrs提出了关于具有许多文件的文件系统的一个非常好的观点。 当需要备份文件系统时，需要很长时间。 文件遍历是备份过程中最大的时间浪费之一，正好与所有这些文件打开/文件closures请求一样。 这个问题“ 在没有或很less使用空间的情况下需要多less时间才能保存映像 ”，这表明这些文件非常小，所以这种types的文件系统几乎是最坏情况备份的文本系统情况（一种情况更糟糕：所有这些文件在一个目录中）。
与真正的数据库相比，将数据库转储到备份是一个非常快速，高效的操作。 是的，那个数据库可能非常大，但它会更快地备份一个LOT，甚至可能随着文件数量的增长而更快地提供数据。 这可能取决于你使用的数据库以及它的pipe理得如何，但是在这种情况下，通常使用数据库存储而不是FS存储将会提供更好的灾难恢复能力。
如果一个数据库不是一个选项，那么是的，预先创build目录结构是最好的select。 还有一个办法，就是在整个结构上对文件进行负载平衡，而不是直到/ 000/000 /被填充之后才移动到/ 000/001 /。 这应该确保每个目录的文件计数在相当长一段时间内保持低水平。
首先，要小心文件系统的限制。 您不会在vanilla EXT3文件系统中存储超过2 ^ 32个文件，因为inode的最大数量有限制（请检查df -i）。 除此之外，还有最大的FS尺寸限制等。
其次：你真的需要在文件系统中的文件？ 根据文件的访问方式，您可能会发现，通过将文件放入数据库，您可以获得更好（更可预测的）性能。 除此之外，数据库更容易处理，备份，移动等。任何涉及数百万个文件的应用程序devise都是有缺陷的，并且在将来会难以忍受。
不要在启动时全部创build它们。
如果你喜欢，可以创build顶级的1k dirs，但是除此之外，他们可以按需提供。 否则，创build它们都会吃掉一堆很可能永远不会使用的文件系统的inode。
考虑：每个目录创build1个inode（inode保存权限和所有权信息，包括文件和目录）。 所以顶级1000个目录是… 1000个inode。 下一级是1000 * 1000或1000000个inode。 一百万，即使在今天的大盘上，也是一笔不小的数目。 如果你用5MB的文件填写1TB的驱动器，这是… 200K的文件。 你将在目录结构上花费更多的inode而不是文件本身。 嘿，你将有更多的目录比文件！