我可以在目录中放入多少个文件？

我保存在一个目录中的文件数量是否重要？如果是这样,目录中有多少文件太多,文件太多会有什么影响？(这是在Linux服务器上.)

背景:我有一个相册网站,上传的每个图像都重命名为8位十六进制数字(例如a58f375c.jpg).这是为了避免文件名冲突(例如,如果上传了大量"IMG0001.JPG"文件).原始文件名和任何有用的元数据都存储在数据库中.现在,我在images目录中有大约1500个文件.这使得列出目录中的文件(通过FTP或SSH客户端)需要几秒钟.但我看不出它除此之外还有什么影响.特别是,对于向用户提供图像文件的速度似乎没有任何影响.

我想过通过制作16个子目录来减少图像数量:0-9和af.然后我会根据文件名的第一个十六进制数字将图像移动到子目录中.但我不确定是否有任何理由这样做,除了偶尔通过FTP/SSH列出目录.

1> ISW..：

---

FAT32:

最大文件数:268,173,300

每个目录的最大文件数:2 ¹⁶  - 1(65,535)

最大文件大小:2 GiB - 1没有LFS,4 GiB - 1有

NTFS:

最大文件数:2 ³²  - 1(4,294,967,295)

最大文件大小

实施:2 ⁴⁴  - 2 ⁶字节(16 TiB - 64 KiB)

理论值:2 ⁶⁴  - 2 ⁶字节(16 EiB - 64 KiB)

最大卷大小

实施:2 ³²  - 1个集群(256 TiB - 64 KiB)

理论值:2 ⁶⁴  - 1个簇(1 YiB - 64 KiB)

ext2:

最大文件数:10 ¹⁸

每个目录的最大文件数:~1.3×10 ²⁰(性能问题超过10,000)

最大文件大小

16 GiB(块大小为1 KiB)

256 GiB(块大小为2 KiB)

2 TiB(块大小为4 KiB)

2 TiB(块大小为8 KiB)

最大卷大小

4 TiB(块大小为1 KiB)

8 TiB(块大小为2 KiB)

16 TiB(块大小为4 KiB)

32 TiB(块大小为8 KiB)

ext3:

最大文件数:min(volumeSize/2 ¹³,numberOfBlocks)

最大文件大小:与ext2相同

最大卷大小:与ext2相同

ext4:

最大文件数:2 ³²  - 1(4,294,967,295)

每个目录的最大文件数:无限制

最大文件大小:2 ⁴⁴  - 1个字节(16 TiB - 1)

最大音量:2 ⁴⁸  - 1字节(256 TiB - 1)

---

我假设这些是整个分区的最大文件数,而不是目录.因此,此信息对于该问题并不太有用,因为无论方法如何,都会有相同数量的文件(除非您将目录计为文件).

---

由于我们现在在2012年,我认为是时候明确表示ext4对子目录的数量没有任何限制.最大文件大小也增加到16 TB.此外,文件系统的总体大小可能高达1 EB = 1,048,576 TB.

---

硬文件系统限制不回答问题"*我在一个目录中保存了多少文件？*"

---

显然,ext3每个目录也有60,000个文件(或目录或链接)的限制.我发现了很难的方法.

---

老答案,我知道......但是当你写**EXT4** - *最大文件数:2³² - 1(4,294,967,295)*和*每个目录的最大文件数:无限制*你真的很困惑我因为2³² - 1!= "无限".我想我现在需要一杯咖啡.;)尽管如此+1

---

请添加ext3(和ext2？)每个目录的限制为32k-2个子目录:http://en.wikipedia.org/wiki/Ext3

2> 小智..：

---

我在一个ext3目录中有超过800万个文件.libc中readdir()这是由使用的find,ls而且大部分在此线程讨论的其他方法,列出大的目录.

在这种情况下原因ls和find速度很慢的是,一次readdir()只能读取32K的目录条目,因此在慢速磁盘上,需要许多次读取才能列出目录.这个速度问题有一个解决方案.我在以下网址写了一篇非常详细的文章:http://www.olark.com/spw/2011/08/you-can-list-a-directory-with-8-million-files-but-not-with- LS /

关键点是:getdents()直接使用- http://www.kernel.org/doc/man-pages/online/pages/man2/getdents.2.html而不是基于libc的任何内容,readdir()因此您可以指定缓冲区从磁盘读取目录条目时的大小.

---

有趣的读!我可以问一下你在一个目录中有8百万个文件的情况吗？哈哈

3> S....：

---

我有一个包含88,914个文件的目录.像你自己一样,它用于存储缩略图和Linux服务器.

通过FTP或php函数列出的文件很慢,但是在显示文件时也会出现性能损失.例如www.website.com/thumbdir/gh3hg4h2b4h234b3h2.jpg的等待时间为200-400毫秒.作为另一个站点的比较,我在一个目录中有大约100个文件,在等待约40ms之后显示图像.

我已经给出了这个答案,因为大多数人刚刚写了目录搜索功能将如何执行,你不会在拇指文件夹上使用 - 只是静态显示文件,但是会对如何实际使用文件的性能感兴趣.

---

这是唯一有用的答案.我们也有类似的经历.我们的限制是1.000文件,以减少备份问题(太多目录也减慢).

---

你在哪个文件系统放慢速度这么慢？例如,XFS应该能够轻松处理目录中的100,000个文件而不会出现明显的减速.

4> Bart Schulle..：

---

它取决于Linux服务器上使用的特定文件系统.现在默认是使用dir_index的ext3,这使得搜索大型目录的速度非常快.

所以速度不应该是一个问题,除了你已经注意到的那个,这是列表需要更长的时间.

一个目录中的文件总数有限制.我似乎记得它肯定能够处理32000个文件.

---

ext3中的一个目录中有大约32K*子目录*的限制,但OP正在讨论图像文件.启用Dir索引的ext3文件系统中的文件没有(实际？)限制.

---

Gnome和KDE以蜗牛的速度加载大型目录,windows将缓存目录以使其合理.我喜欢Linux,但kde和gnome编写得很糟糕.

5> Steve Kuo..：

---

请记住,在Linux上,如果您的目录文件太多,则shell可能无法扩展通配符.我在Linux上托管的相册中存在此问题.它将所有已调整大小的图像存储在单个目录中.虽然文件系统可以处理许多文件,但shell不能.例:

-shell-3.00$ ls A*
-shell: /bin/ls: Argument list too long

要么

-shell-3.00$ chmod 644 *jpg
-shell: /bin/chmod: Argument list too long

---

@Steve,对这些情况使用find(1)和/或xargs(1).出于同样的原因,在脚本中使用这些工具而不是命令行扩展是个好主意.

---

这是一个好点,但对于挑剔,给出的理由是错误的.*Argument列表太长*不是shell的限制,而是系统的`exec`实现的限制.shell通常可以很好地扩展通配符 - 它是使用许多返回错误的参数调用`exec`.

---

@Steve当文件夹中的文件数量增加时,您是否看到性能下降？或者没有关系？

6> armandino..：

---

我现在正在研究类似的问题.我们有一个层次结构的目录结构,并使用图像ID作为文件名.例如,id=1234567放入的图像

..../45/67/1234567_<...>.jpg

使用最后4位数来确定文件的去向.

使用几千个图像,您可以使用一级层次结构.我们的系统管理员建议在任何给定目录(ext3)中只有几千个文件用于效率/备份/他想到的任何其他原因.

7> T.J. Crowder..：

---

为了它的价值,我只是在ext4文件系统上创建了一个目录,其中包含1,000,000个文件,然后通过Web服务器随机访问这些文件.我没有注意到访问那些(例如)那里只有10个文件的溢价.

这与我几年前这样做的经历截然不同ntfs.

8> 小智..：

---

我遇到的最大问题是32位系统.一旦你传递了一定数量,像'ls'这样的工具就会停止工作.

一旦通过该障碍,尝试对该目录执行任何操作都会成为一个大问题.

9> Javier..：

---

它实际上取决于所使用的文件系统,还有一些标志.

例如,ext3可以有数千个文件; 但是在成千上万之后,它过去很慢.主要是在列出目录时,也是在打开单个文件时.几年前,它获得了"htree"选项,大大缩短了获取带有文件名的inode所需的时间.

就个人而言,我使用子目录将大多数级别保持在大约一千个左右的项目中.在您的情况下,我将创建256个目录,其中包含ID的两个最后十六进制数字.使用最后一位而不是第一位数字,这样就可以获得负载平衡.

---

如果文件名完全是随机的,那么使用哪个数字无关紧要.

---

或使用文件名SHA-1摘要的前N个字节。

10> Sparr..：

---

如果实现目录分区方案所涉及的时间很少,我赞成它.第一次必须调试涉及通过控制台操作10000文件目录的问题时,您将理解.

例如,F-Spot将照片文件存储为YYYY\MM\DD\filename.ext,这意味着我必须处理的最大目录,而手动操作我的~20000照片集大约是800个文件.这也使得文件更容易从第三方应用程序中浏览.永远不要假设您的软件是唯一可以访问您的软件文件的东西.

---

我做广告反对按日期分区,因为批量导入可能会在某个特定日期对文件进行集群.

11> Michael Borg..：

---

它绝对取决于文件系统.许多现代文件系统使用不错的数据结构来存储目录的内容,但是较旧的文件系统通常只是将条目添加到列表中,因此检索文件是O(n)操作.

即使文件系统做得正确,列出目录内容的程序仍然绝对可能搞乱并进行O(n ^ 2)排序,所以为了安全起见,我总是限制每个文件的数量目录不超过500.

12> dataless..：

---

ext3实际上确实具有目录大小限制，并且它们取决于文件系统的块大小。没有每个目录的“最大数量”的文件，而是每个目录的“用于存储文件条目的最大块的数量”。具体来说，目录本身的大小不能超过高度为3的b树，并且树的扇出取决于块大小。有关更多详细信息，请参见此链接。

https://www.mail-archive.com/cwelug@googlegroups.com/msg01944.html

最近，我在一个以2K块格式化的文件系统上被这个问题所困扰，warning: ext3_dx_add_entry: Directory index full!当我从另一个ext3文件系统复制时，该文件系统莫名其妙地得到了目录已满的内核消息。就我而言，只有480,000个文件的目录无法复制到目标位置。

13> Hartator..：

---

我一直遇到同样的问题。试图在ext4的Ubuntu服务器中存储数百万个文件。结束了运行自己的基准测试。发现平面目录在使用更简单的同时性能更好：

写了一篇文章。