NTFS性能和大量的文件和目录
Windows与NTFS如何执行大量的文件和目录？
在遇到性能问题或其他问题之前，是否有任何关于文件或目录限制的指导，您可以将它们放在单个目录中？ 例如，一个文件夹里面有100,000个文件夹是一件好事
这里有一些人的build议，我们有一个文件夹包含数以千万计的文件的环境。
- 文件夹将索引信息（链接到子文件和子文件夹）存储在索引文件中。 当你有很多孩子的时候这个文件会变得很大。 请注意，它不区分是一个文件夹的孩子和一个文件的孩子。 唯一不同的是，该孩子的内容是孩子的文件夹索引或孩子的文件数据。 注：我正在简化这个有点，但这得到了重点。
- 索引文件将被分割。 当它太碎片化，你将无法添加文件到该文件夹。 这是因为允许的碎片数量有限制。 这是devise。 我已经通过支持事件电话向微软证实了这一点。 因此，尽pipe对文件夹中的文件数量的理论限制是几十亿，但是当您开始打印数千万个文件时，您将会碰到碎片限制。
- 不过并不全是坏事。 你可以使用这个工具： contig.exe去整理这个索引。 它不会减小索引的大小（对于数千万个文件可以达到几个Gig），但是可以减less碎片的数量。 注意：“磁盘碎片整理”工具不会对文件夹的索引进行碎片整理。 它会整理文件数据。 只有contig.exe工具将碎片整理索引。 仅供参考：您也可以使用它来整理单个文件的数据。
- 如果你做碎片整理，不要等到你达到最大片段限制。 我有一个文件夹，我不能碎片整理，因为我一直等到太晚了。 我的下一个testing是尝试将文件夹中的某些文件移动到另一个文件夹，以查看是否可以对其进行碎片整理。 如果这失败了，那么我将不得不做的是1）创build一个新的文件夹。 2）将一批文件移动到新的文件夹。 3）整理新的文件夹。 重复＃2＆＃3直到完成，然后4）删除旧的文件夹，并重命名新的文件夹以匹配旧的。
要更直接地回答你的问题：如果你正在看100K条目，不用担心。 去敲你自己。 如果您正在查看数以千万计的条目，则可以：
a）制定计划把它们分成多个子文件夹（例如，假设你有100M文件，最好将它们存储在1000个文件夹中，这样每个文件夹只有10万个文件，而不是存储在1个大文件夹中。将创build1000个文件夹索引，而不是一个大的文件夹索引，而这个文件索引更有可能达到最大分片限制或
b）制定计划定期运行contig.exe，以保持您的大文件夹的索引经过碎片整理。
只有在无聊的时候才能阅读下面的内容。
实际限制不是在片段的＃号上，而是在存储指向片段的指针的数据段的logging数上。
所以你所拥有的是一个存储指向目录数据片段指针的数据段。 目录数据存储关于目录应该存储的子目录和子文件的信息。 实际上，一个目录不会“存储”任何东西。 这只是一个跟踪和呈现function，因为存储介质本身是线性的，所以呈现给用户的层次错觉。
还有短文件名创build放慢速度的性能问题。 如果文件夹中有超过300k个文件[1]，Microsoftbuild议closures短文件名创build。 前6个字符的独特性越低，问题就越严重。
[1] NTFS如何从http://technet.microsoft.com工作; ，search“300,000”
我构build了一个文件结构来承载多达20亿（2 ^ 32）文件，并执行以下testing，显示在固态驱动器上大约250个文件或120个目录每个NTFS目录的导航+读取性能SSD）：
- 文件性能在250到1000个文件之间下降50％。
- 目录性能在120和1000目录之间下降60％。
- 数字> 1000的值保持相对稳定
有趣的是，目录和文件的数量不会显着干扰。
所以教训是：
- 大于250的文件数量是2的因数
- 目录超过120的成本是2.5的因素
- 在Windows 7中的文件资源pipe理器可以处理大#Files或#Dirs，但可用性仍然不好。
- 介绍子目录并不昂贵
这是数据（每个文件和目录的2次测量）：
(FOPS = File Operations per Second) (DOPS = Directory Operations per Second) #Files lg(#) FOPS FOPS2 DOPS DOPS2 10 1.00 16692 16692 16421 16312 100 2.00 16425 15943 15738 16031 120 2.08 15716 16024 15878 16122 130 2.11 15883 16124 14328 14347 160 2.20 15978 16184 11325 11128 200 2.30 16364 16052 9866 9678 210 2.32 16143 15977 9348 9547 220 2.34 16290 15909 9094 9038 230 2.36 16048 15930 9010 9094 240 2.38 15096 15725 8654 9143 250 2.40 15453 15548 8872 8472 260 2.41 14454 15053 8577 8720 300 2.48 12565 13245 8368 8361 400 2.60 11159 11462 7671 7574 500 2.70 10536 10560 7149 7331 1000 3.00 9092 9509 6569 6693 2000 3.30 8797 8810 6375 6292 10000 4.00 8084 8228 6210 6194 20000 4.30 8049 8343 5536 6100 50000 4.70 7468 7607 5364 5365
这是testing代码：
[TestCase(50000, false, Result = 50000)] [TestCase(50000, true, Result = 50000)] public static int TestDirPerformance(int numFilesInDir, bool testDirs) { var files = new List<string>(); var dir = Path.GetTempPath() + "\\Sub\\" + Guid.NewGuid() + "\\"; Directory.CreateDirectory(dir); Console.WriteLine("prepare..."); const string FILE_NAME = "\\file.txt"; for (int i = 0; i < numFilesInDir; i++) { string filename = dir + Guid.NewGuid(); if (testDirs) { var dirName = filename + "D"; Directory.CreateDirectory(dirName); using (File.Create(dirName + FILE_NAME)) { } } else { using (File.Create(filename)) { } } files.Add(filename); } //Adding 1000 Directories didn't change File Performance /*for (int i = 0; i < 1000; i++) { string filename = dir + Guid.NewGuid(); Directory.CreateDirectory(filename + "D"); }*/ Console.WriteLine("measure..."); var r = new Random(); var sw = new Stopwatch(); sw.Start(); int len = 0; int count = 0; while (sw.ElapsedMilliseconds < 5000) { string filename = files[r.Next(files.Count)]; string text = File.ReadAllText(testDirs ? filename + "D" + FILE_NAME : filename); len += text.Length; count++; } Console.WriteLine("{0} File Ops/sec ", count / 5); return numFilesInDir; }
10万应该没事的。
我（有趣的）看到人们有数百万个文件的问题，而且我自己也遇到了一些问题，就是不知道如何计算60多万个文件，但是NTFS对于你所说的数量应该是好的。
如果你想知道，技术（我希望理论上 ）最大文件数是：4,294,967,295
对于本地访问，大量的目录/文件似乎不成问题。 但是，如果你通过networking访问它，几百次之后会有明显的性能下降（尤其是从Vista计算机访问时（XP到Windows Server / NTFS似乎在这方面运行得更快））。
在创build具有N个条目的文件夹时，可以在文件系统级别创buildN个项目的列表。 这个列表是一个系统范围的共享数据结构。 如果你开始通过添加/删除条目来不断修改这个列表，我希望至less有一些锁共享数据的争用。 这个争论在理论上可能会对业绩产生负面影响。
对于只读场景，我无法想象任何有大量条目的目录性能下降的原因。
我有一个真实的经验，在复制一个在线图书馆的时候，在一个目录的ntfs上有大约100 000个文件（每个几十MB）。 用explorer或7-zip打开dir大约需要15分钟。 用winhttrack写的网站拷贝总会在一段时间后卡住的。它还处理目录，包含大约1000 000个文件。 我认为最糟糕的是MFT只能按顺序遍历。
在ext3的ext2fsd下打开同样的时间。 可能移动到reiserfs（而不是reiser4fs）可以帮助。
试图避免这种情况可能是最好的。
对于你自己的程序使用Blob W / O任何FS可能是有益的。 这就是Facebook存储照片的方式。
干杯。
