在一个目录中保存多少文件有关系吗?如果是，一个目录中有多少文件是太多的，拥有太多文件的影响是什么?(这是在Linux服务器上。)
Background: I have a photo album website, and every image uploaded is renamed to an 8-hex-digit id (say, a58f375c.jpg). This is to avoid filename conflicts (if lots of "IMG0001.JPG" files are uploaded, for example). The original filename and any useful metadata is stored in a database. Right now, I have somewhere around 1500 files in the images directory. This makes listing the files in the directory (through FTP or SSH client) take a few seconds. But I can't see that it has any effect other than that. In particular, there doesn't seem to be any impact on how quickly an image file is served to the user.
我想过通过创建16个子目录来减少图像的数量:0-9和a-f。然后我将根据文件名的第一个十六进制数字将图像移动到子目录中。但是除了偶尔通过FTP/SSH列出目录之外，我不确定这样做是否有任何理由。
FAT32:
最大文件数:268,173,300
每个目录的最大文件数:216 - 1 (65,535)
最大文件大小:2 GiB - 1无LFS, 4 GiB - 1有
NTFS:
最大文件数:232 - 1 (4,294,967,295)
最大文件大小
实现:244 - 26字节(16 TiB - 64 KiB)
理论:264 - 26字节(16 EiB - 64 KiB)
最大卷大小
实现:232 - 1个集群(256tib - 64kib)
理论:264 - 1个集群(1 YiB - 64 KiB)
ext2:
最大文件数:1018
每个目录的最大文件数:~1.3 × 1020(性能问题超过10,000)
最大文件大小
16gib(每块大小为1kib)
256gib(区块大小为2kib)
2 TiB(区块大小4 KiB)
2 TiB(块大小为8 KiB)
最大卷大小
4 TiB(区块大小为1kib)
8 TiB(区块大小为2 KiB)
16 TiB(区块大小为4 KiB)
32 TiB(块大小为8 KiB)
ext3:
最大文件数:min(volumeSize / 213, numberOfBlocks)
最大文件大小:与ext2相同
最大卷大小:与ext2相同
ext4:
最大文件数:232 - 1 (4,294,967,295)
每个目录的最大文件数:无限制
最大文件大小:244 - 1字节(16tib - 1)
最大卷大小:248 - 1字节(256tib - 1)
上面的大多数答案都没有说明，对于最初的问题，没有“一刀切”的答案。
In today's environment we have a large conglomerate of different hardware and software -- some is 32 bit, some is 64 bit, some is cutting edge and some is tried and true - reliable and never changing.
Added to that is a variety of older and newer hardware, older and newer OSes, different vendors (Windows, Unixes, Apple, etc.) and a myriad of utilities and servers that go along.
As hardware has improved and software is converted to 64 bit compatibility, there has necessarily been considerable delay in getting all the pieces of this very large and complex world to play nicely with the rapid pace of changes.
恕我直言，没有一种方法可以解决问题。解决办法是研究各种可能性，然后通过反复试验找到最适合你特定需求的方法。每个用户必须确定什么适合他们的系统，而不是使用千篇一律的方法。
I for example have a media server with a few very large files. The result is only about 400 files filling a 3 TB drive. Only 1% of the inodes are used but 95% of the total space is used. Someone else, with a lot of smaller files may run out of inodes before they come near to filling the space. (On ext4 filesystems as a rule of thumb, 1 inode is used for each file/directory.)
While theoretically the total number of files that may be contained within a directory is nearly infinite, practicality determines that the overall usage determine realistic units, not just filesystem capabilities.
我希望以上所有不同的答案都能促进思考和解决问题，而不是成为进步的不可逾越的障碍。
≈13.5万份
NTFS | Windows 2012 server | 64bit | 4tb HDD | VBS
问题:当[单个]特定文件夹聚集了大约135,000个文件时，会出现灾难性的硬件问题。
“灾难性”= CPU过热，计算机关闭，更换硬件需要
"Specific Folder" =有一个VBS文件，用于将文件移动到子文件夹中
访问=该文件夹被多个客户端计算机自动访问/执行
基本上，我有一个位于文件服务器上的定制脚本。当自动化过程出现问题时(例如，文件溢出+大坝)，那么特定的文件夹会被淹没[未移动的文件]。当客户端计算机继续执行脚本时，灾难就形成了。文件服务器最终读取了135,000多个文件;每天这样做几百次。这种工作过载最终导致我的CPU过热(92°C等);结果导致我的机器崩溃。
解决方案:确保您的文件组织脚本永远不必处理包含135,000多个文件的文件夹。
