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)

完美的,

完美的,

完美无瑕:

(g.m. - rip)

function ff () { 
    d=$1; f=$2; 
    p=$( echo $f |sed "s/$d.*//; s,\(.\),&/,g; s,/$,," ); 
    echo $p/$f ; 
    }


ff _D_   09748abcGHJ_D_my_tagged_doc.json

0/9/7/4/8/a/b/c/G/H/J/09748abcGHJ_D_my_tagged_doc.json


ff -   gadsf12-my_car.json 

g/a/d/s/f/1/2/gadsf12-my_car.json

还有这个

ff _D_   0123456_D_my_tagged_doc.json

0/1/2/3/4/5/6/0123456_D_my_tagged_doc.json



ff .._D_   0123456_D_my_tagged_doc.json

0/1/2/3/4/0123456_D_my_tagged_doc.json

享受吧!

我遇到的最大问题是在32位系统上。一旦你通过了一个特定的数字，像'ls'这样的工具就会停止工作。

一旦您通过了这个障碍，试图对该目录做任何事情都将成为一个巨大的问题。

这完全取决于文件系统。许多现代文件系统使用良好的数据结构来存储目录的内容，但旧的文件系统通常只是将条目添加到列表中，因此检索文件是一个O(n)操作。

即使文件系统做得正确，列出目录内容的程序仍然绝对有可能搞砸并执行O(n^2)排序，因此为了安全起见，我总是将每个目录的文件数量限制在不超过500个。

这实际上取决于所使用的文件系统，以及一些标志。

例如，ext3可以有数千个文件;但在几千次之后，它就变得非常缓慢了。主要是在列出目录时，但也在打开单个文件时。几年前，它获得了“htree”选项，这极大地缩短了给定文件名获取inode所需的时间。

就我个人而言，我使用子目录将大多数级别保持在1000个左右的项目以下。在您的例子中，我将创建256个目录，使用ID的最后两个十六进制数字。使用最后一个数字，而不是第一个数字，这样可以实现负载平衡。

≈13.5万份

NTFS | Windows 2012 server | 64bit | 4tb HDD | VBS

问题:当[单个]特定文件夹聚集了大约135,000个文件时，会出现灾难性的硬件问题。

“灾难性”= CPU过热，计算机关闭，更换硬件需要 "Specific Folder" =有一个VBS文件，用于将文件移动到子文件夹中 访问=该文件夹被多个客户端计算机自动访问/执行

基本上，我有一个位于文件服务器上的定制脚本。当自动化过程出现问题时(例如，文件溢出+大坝)，那么特定的文件夹会被淹没[未移动的文件]。当客户端计算机继续执行脚本时，灾难就形成了。文件服务器最终读取了135,000多个文件;每天这样做几百次。这种工作过载最终导致我的CPU过热(92°C等);结果导致我的机器崩溃。

解决方案:确保您的文件组织脚本永远不必处理包含135,000多个文件的文件夹。