我正在编写一个应用程序，用于在 ext3 文件系统上存储大量图像（大小 <5MB），这是我目前所拥有的。在 serverfault 上搜索后，我决定采用如下目录结构：
000/000/000000001.jpg
...
236/519/236519107.jpg
这种结构将允许我保存最多 1'000'000'000 张图像，因为我将在每片叶子中最多存储 1'000 张图像。
我已经创建了它，从理论的角度来看对我来说似乎没问题（虽然我没有这方面的经验），但我想知道当目录中充满文件时会发生什么。
关于创建此结构的一个问题：是一次性创建所有目录更好（在我的 PC 上大约需要 50 分钟）还是应该根据需要创建目录？从开发人员的角度来看，我认为第一个选项更好（用户无需额外等待），但从系统管理员的角度来看，这样可以吗？
我认为我可以这样做，就好像文件系统已经在正在运行的应用程序下一样，我将编写一个脚本，以尽快保存图像，并监控如下情况：
- 当没有使用空间或使用空间很少时，保存图像需要多长时间？
- 当空间开始被用完时，情况会如何变化？
- 从一片随机叶子中读取图像需要多长时间？当有大量文件时，这种情况会发生很大变化吗？
启动此命令
sync; echo 3 | sudo tee /proc/sys/vm/drop_caches
有什么意义吗？如果我想重新开始测试，这是我唯一需要做的事情吗？
您有什么建议或更正吗？
编辑：由于以下两个问题，我选择了文件系统，而不是数据库：
答案1
Pehrs 就包含如此多文件的文件系统提出了一个很好的观点。当需要备份文件系统时，它将花费非常长的时间。文件遍历是备份过程中最耗时的操作之一，与所有文件打开/文件关闭请求一样。问题是“当没有使用空间或使用空间很少时，保存图像需要多长时间？“表明这些文件会非常小，所以这种类型的文件系统几乎就是最坏备份场景的教科书（一种情况更糟糕：所有这些文件都在一个目录中）。
与真正的数据库相比，将数据库转储到备份是一项非常快速、高效的操作。是的，该数据库可能非常大，但它的备份速度会快得多，甚至可能随着文件数量的增加而更快地提供数据。这取决于您使用的数据库及其管理情况，但在这种情况下，通常使用数据库存储而不是文件系统存储将提供更好的灾难恢复能力。
如果 DB 不是一个选项，那么是的，预先创建目录结构是您的最佳选择。还有一种帮助是在整个结构中平衡文件创建的负载，而不是一直到 /000/000/ 填满后才转到 /000/001/。这应该可以确保每个目录的文件数量在相当长的一段时间内保持较低水平。
答案2
首先，请注意文件系统的限制。在普通的 EXT3 文件系统中，您存储的文件数量永远不能超过 2^32 个，因为 inode 的最大数量是有限制的（检查 df -i）。除此之外，还需要考虑最大 FS 大小限制等。
其次：您真的需要将文件放在文件系统中吗？根据访问文件的方式，您可能会发现将文件放入数据库可以获得更好（且更可预测）的性能。除此之外，数据库更容易处理、备份、移动等。任何涉及数百万个文件的应用程序设计都是有缺陷的，将来会给您带来严重困扰。
答案3
做不是在启动时创建它们。
如果您愿意，可以创建顶层 1k 目录，但除此之外，请按需创建。否则，创建所有目录将占用大量文件系统的 inode，而这些 inode 很可能永远不会被使用。
考虑一下：每个目录创建都会消耗 1 个 inode（inode 保存文件和目录的权限和所有权信息）。因此，顶层 1000 个目录是... 1000 个 inode。下一级是 1000*1000 或 1000000 个 inode。一百万，即使在今天的大磁盘上也是一个不小的数量。如果您用 5MB 文件填充 1TB 驱动器，那就是... 200k 个文件。您在目录结构上花费的 inode 比在文件本身上花费的还要多。哎呀，您的目录将比文件还多！