Linux上的文件/文件夹的最大数量？
我正在开发一个LAMP网上商店，这将允许pipe理员上传每个项目的多个图像。
我的担心是 – 即将离开蝙蝠，将会有20000个项目，这意味着大约60000图像。
问题：
-
Linux上的文件和/或文件夹的最大数量是多less？
-
处理这种情况的通常方法是什么（最佳做法）？
我的想法是根据每个项目的唯一ID为每个项目创build一个文件夹，但是在主上传文件夹中仍然有20000个文件夹，并且无限期地增长，因为旧项目不会被删除。
谢谢你的帮助。
ext [234]文件系统具有固定的最大数量的inode; 每个文件或目录都需要一个inode。 您可以使用df -i查看当前的计数和限制。 例如，在使用默认设置创build的15GB ext3文件系统上：
Filesystem Inodes IUsed IFree IUse% Mounted on /dev/xvda 1933312 134815 1798497 7% /
特别是目录没有限制，除此之外， 请记住，每个文件或目录至less需要一个文件系统块（通常为4KB），尽pipe它只是一个只包含单个项目的目录。
但是，正如你所看到的，8万个inode不太可能成为问题。 而用dir_index选项（用tune2fs可用），在大目录中查找并不是什么大不了的事情。 但是请注意，许多pipe理工具（如ls或rm ）可能很难处理文件太多的目录。 因此，build议将文件拆分，以便在任何给定的目录中没有超过几百到一千个项目。 一个简单的方法就是把你正在使用的任何ID散列起来，并把前几个hex数字作为中间目录。
例如，假设您的商品ID为12345，并且哈希为'DEADBEEF02842.......' 。 您可以将文件/storage/root/d/e/12345在/storage/root/d/e/12345 。 您现在已经将每个目录中的文件数量减less了1/256。
如果您的服务器的文件系统dir_index了dir_indexfunction（有关检查和打开function的详细信息，请参阅tune2fs(8) ），那么在性能下降之前，您可以在目录中合理存储100,000个以上的文件。 （ dir_index已经是多年来大多数发行版的新文件系统的默认值了，所以它只是一个旧的文件系统，默认情况下它没有这个function）。
也就是说，添加另一个目录级别以将目录中的文件数量减less16或256倍，将显着提高诸如ls *工作的可能性，而不会超出内核的最大argv大小。
通常情况下，这是通过如下所示完成的：
/a/a1111 /a/a1112 ... /b/b1111 ... /c/c6565 ...
即在path前面添加一个字母或数字，根据可以计算出名称的某些function。 （文件名md5sum或sha1sum的前两个字符是一个常用的方法，但是如果你有唯一的对象id，那么'a'+ id % 16就足够容易确定使用哪个目录了。
60000不算什么，20000也是。 但是你应该以任何方式将这两个组合放在一起，以加速访问它们。 也许在100或1000的组，通过目录的数量除以100，500，1000，无论如何。
例如，我有一个文件有数字的项目。 我把他们在1000年代，所以我有
id/1/1332 id/3/3256 id/12/12334 id/350/350934
你实际上可能有一个硬性的限制 – 一些系统有32位inode，所以你被限制在每个文件系统2 ^ 32的数目。
除了一般的答案（基本上“不要打扰那么多”，“调整你的文件系统”，以及“用包含几千个文件的子目录来组织你的目录”）：
如果单个图像很小（例如小于几千字节），则可以将它们放在数据库中（例如，将MySQL作为BLOB ），或者放在GDBM索引文件中，而不是放在一个文件夹中。 那么每个小项目将不会消耗一个inode（在许多文件系统上，每个inode至less需要几千字节）。 你也可以做一些阈值（例如，在单个文件中放大大于4k字节的图像，在数据库或GDBM文件中放大小于4k字节的图像）。 当然，不要忘记备份你的数据（并定义备份状态）。
今年是2014年。我回来的时候添加这个答案。 很多大/小文件？ 您可以使用基于Ceph的Amazon S3和其他替代品，如DreamObjects，其中没有目录限制。
我希望这可以帮助别人从所有的select决定。
md5($id) ==> 0123456789ABCDEF $file_path = items/012/345/678/9AB/CDE/F.jpg 1 node = 4096 subnodes (fast)
