Linux或者Win服务器,极限情况下一个文件夹能放多少文件

决定一个文件夹下能存放多少个文件的，是文件系统，而不是操作系统。文件系统是给硬盘分区格式化时选择的格式。Windows有两种主流的文件系统：FAT32和NTFSFAT32 标称为单目录下最高支持65534个文件，实际到2万+时已不稳定。NTFS 似乎没有明确限制单目录文件数量，但有人反应在生成10万+ 文件的目录时遇到报错，想来应该是和文件属性（文件名等）、磁盘使用状况相关，至于对效率的影响，可以参考以下内容，以下内容为转载 似乎 FAT32 文件系统下的单一目录下的文件数限制在 20000 -30000 之间的一个数字。。。具体就不知道是哪个了。

。因为我在 解压一个有 30000 多个文件的 rar 文件到 fat32 目录的时候出现磁盘满的提示。。但是磁盘并没有满。。。每个目录都要描述它的内容所在的磁盘位置，名字等信息。

这些信息是连续存放的，而且空间有限，用完了就不能再加了。

改进的文件系统，目录信息自身也是在磁盘上不连续分布的，就没有这个问题了。不过一般来讲这个都不是问题。在文件很多的系统中，往往会自己创建子目录进行分类。

比如VSS.对于 FAT16文件系统，可以保存的文件体积最大值是 4 GB - 1 byte (2^32 bytes - 1 byte)；

卷的最大体积是4GB；每个卷上最多可以保存的文件数量是65,536个 (2^16)；根目录下可以保存的文件和文件夹数量最大值是512个（如果使用了长文件名，该数字还会减小）

对于FAT32文件系统， 可以保存的文件体积最大值是 4 GB - 1 byte (2^32 bytes - 1 byte)；Windows自带的工具可以创建的卷的最大体积是32GB；每个卷中最多可以保存的文件数量是4,177,920个；

一个特定文件夹中最多可以保存的子文件夹和文件的数量是65,534（如果使用了长文件名，那么该数字会减小）对于NTFS文件系统，

可以保存的文件的大小的最大值，理论上是16EB - 1 KB (2^64 bytes - 1 KB)(1EB=1024PB=1024TB=1024GB) ，实际实现过的最大值是16TB - 64 KB (2^44 bytes - 64 KB)；卷的体积最大值，理论上可以达到2^64个簇 - 1个簇，实际实现过的最大值是2^56 TB - 64 KB ( 2^32 个簇 - 1个簇)；

每个卷可以包含的文件个数的最大值是4,294,967,295个 (2^32 - 1)理论上FAT32单个目录下，最多可以包括65534个子目录或者文件。但是如果采用长文件名命名的话，实际可以容纳的文件数目会远远小于6万多。

2万多属于正常现象。

NTFS克服了这个问题，但是对于单个目录下多文件的操作（拷贝，移动或者删除），比如说几万个小文件，每个十几k大，仍然十分头疼，个人觉得是死穴，也是正常现象。

Linux的文件系统就多了去了：ext2, ext3, ext4, reiserfs, cramfs, jfs, xfs, bfs等等等等……我无法给你逐一列举，但是可以确定的告诉你，Linux就是用来作服务器的，主流的三种分区格式ext3, ext4, reiserfs不会有个人用户有能力达到其最高容量的，你的硬盘尺寸肯定都达不到不到他们的“最大文件尺寸”限制。

 我曾经给Linux服务器的一整块76G硬盘dump成一个76G的文件，再大也没问题。

对于FAT16文件系统，可以保存的文件体积最大值是 4 GB 
- 1 byte (2^32 bytes - 1 
byte)；卷的最大体积是4GB；每个卷上最多可以保存的文件数量是65,536个 
(2^16)；根目录下可以保存的文件和文件夹数量最大值是512个（如果使用了长文件名，该数字还会减小） 


对于FAT32文件系统， 可以保存的文件体积最大值是 4 GB 
- 1 byte (2^32 bytes - 1 
byte)；Windows自带的工具可以创建的卷的最大体积是32GB；每个卷中最多可以保存的文件数量是4,177,920个；一个特定文件夹中最多可以保­存的子文件夹和文件的数量是65,534（如果使用了长文件名，那么该数字会减小） 


对于NTFS文件系统，可以保存的文件的大小的最大值，理论上是16EB 
- 1 KB (2^64 bytes - 1 KB)(1EB=1024PB=1024TB=1024GB) 
，实际实现过的最大值是16TB - 64 KB (2^44 bytes - 64 
KB)；卷的体积最大值，理论上可以达到2^64个簇 - 
1个簇，实际实现过的最大值是2^56 TB - 64 KB ( 2^32 个簇 - 
1个簇)；每个卷可以包含的文件个数的最大值是4,294,967,295个 
(2^32 - 1)

0

Windows下我的文件夹有过50000左右的图片，没感到效率问题 这方面NTFS比FAT32要强很多，服务器永远也不应该跑FAT32分区 Linux下没有尝试过 

NTFS以上可以存储无数个，但是移动，检索性能会大幅度降低。

文件系统：FAT32、NTFS、exFAT和HFS+

　　FAT32

　　FAT32最早出现在1997年的Windows 95B中，几乎所有主流操作系统都可以创建、读取和写入FAT32分区，对于低容量外部存储(例如USB闪存驱动器)FAT32仍然是一个不错的选择。现代操作系统在默认情况下选择NTFS，Mac操作系统运行HFS+。

　　作为一个32位文件系统，FAT32被限制为最大分区大小32TB，8KB簇，虽然这种格式的原来格式限制被限制为最大分区2TB，而当前Windows操作系统让其难以使FAT32分区大于32GB。簇大小直接取决于分区大小，簇的范围从512字节到8KB之间。由于文件大小被存储在4字节字段中，最大文件大小限制为4GB。这对于视频文件或者驱动器镜像而言，将是一个问题。文件名是灵活地，允许最多255字符。FAT32并不支持日志(journaling)，这意味着用户数据或元数据的完整性问题可能导致信息丢失。FAT32不支持权限管理。

　　Windows XP提供安装到FAT32分区的选项，而Windows Vista和7并不提供，因为它们依赖于NTFS。

　　NTFS

　　新技术文件系统与Windows NT一起推出，与IBM的HPFS很类似。文件大小可以高达16TB(理论上是16EB)，而分区目前最大可达256TB。其文件大小限制与FAT32的4GB相比更具现实意义。文件名最多可长达255字符。NTFS支持LZ77压缩、文件级加密(通常是AES)和访问控制，通过ACL管理。4KB(FAT32为32KB)簇大小确保写入驱动器的小文件不会浪费太多容量。这也是为什么4KB簇大小对SSD性能的重要性，你会发现，NTFS比其他文件系统更具优势。

　　主文件表(Master File Table，以下简称MFT)存储文件的属性、位置和访问信息。最小的文件直接被保存在MFT中。与文件分配表不同，MFT在格式化过程中并不会被完全写入，会随着时间的推移而增长。正因为如此，它是唯一可以经受碎片的。它还能够日志记录元数据，这意味着写入操作先被记录，写入程序再执行，日志中会记录成功完成的结果。写入过程会因为电源故障而失败吗?例如，系统恢复之前写入的日志和恢复到稳定的文件系统状态。

　　exFAT

　　exFAT是微软专门设计来处理闪存的，高容量SDXC卡都采用了exFAT，虽然并没有严格要求使用。所有现有Windows版本(从Vista SP1或XP SP2起)都支持exFAT，高达64ZB，文件高达16EB。与FAT32不同，其簇可以增加到32MB，访问控制通过ACL管理。自由空间位图负责容量分配，提高删除性能。这能够最大程度的提高写入性能，尤其是与NTFS相比，NTFS要求被删除的数据被覆盖。

　　然而，因为微软的exFAT授权机制，该文件系统并没有像FAT32和NTFS一样受到广泛支持。因此，exFAT还没有广泛应用于消费类电子产品，尽管它就是为此目的而设计(即使XP SP2和Mac OS X 10.6.5都支持exFAT)。Windows Vista和7在很大程度上依赖于NTFS提供的文件权限和其他功能。

　　HFS+

　　HFS+也被称为Mac OS Extended， 它能够在所有类型的存储设备上运作，包括光盘。HFS+支持日志，且分袂通常可以安装在Unix和Linux系统中。即使给定内核不支持HFS+，通常可以找到可选软件包，然而，有时候这些只支持读取HFS+格式化的分区。另外还有第三方工具提供Windows对HFS+的支持，例如Paragon Software的HFS for Windows或者Mediafour的MacDrive。

　　HFS+具有512字节扇区(被分组成分配块)，最多支持255个字符的文件名，最大文件大小为8EB。HFS+通过不断尝试寻找足够容纳一个被写入文件的自由空间来管理文件碎片。文件大小的增加可能会导致文件需要完全被重写。最后，自10.3版本的Mac OS X开始支持动态碎片整理，当文件被分为8个以上部分且其他活动/访问先决条件不适用时就会采取行动，HFS+支持访问控制、压缩和加密。

512个是根目录限制，其他目录还是没关系的。
ntfs和linux ext3应该都有限制，

这可能有硬盘技术决定，和分区性质无关

更多的是IO问题，那么如果是固态硬盘会好很多。