在一个目录中保存多少文件有关系吗?如果是，一个目录中有多少文件是太多的，拥有太多文件的影响是什么?(这是在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)
我在一个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/上写了一篇非常详细的文章
关键是:直接使用getdings()——http://www.kernel.org/doc/man-pages/online/pages/man2/getdents.2.html，而不是任何基于libc readdir()的方法，这样在从磁盘读取目录条目时就可以指定缓冲区大小。
≈13.5万份
NTFS | Windows 2012 server | 64bit | 4tb HDD | VBS
问题:当[单个]特定文件夹聚集了大约135,000个文件时，会出现灾难性的硬件问题。
“灾难性”= CPU过热，计算机关闭，更换硬件需要
"Specific Folder" =有一个VBS文件，用于将文件移动到子文件夹中
访问=该文件夹被多个客户端计算机自动访问/执行
基本上，我有一个位于文件服务器上的定制脚本。当自动化过程出现问题时(例如，文件溢出+大坝)，那么特定的文件夹会被淹没[未移动的文件]。当客户端计算机继续执行脚本时，灾难就形成了。文件服务器最终读取了135,000多个文件;每天这样做几百次。这种工作过载最终导致我的CPU过热(92°C等);结果导致我的机器崩溃。
解决方案:确保您的文件组织脚本永远不必处理包含135,000多个文件的文件夹。
