NTFS性能以及大量文件和目录

带有NTFS的Windows如何处理大量文件和目录？

在遇到性能问题或其他问题之前，是否可以围绕单个目录中的文件或目录限制提供任何指导？

例如，其中有一个包含100,000个文件夹的文件夹，可以这样做吗？

这是来自某人的一些建议，该人的环境中我们的文件夹包含数千万个文件。

1. 文件夹将索引信息（指向子文件和子文件夹的链接）存储在索引文件中。当您有很多孩子时，此文件将变得非常大。请注意，它不能区分作为文件夹的子项和作为文件的子项。唯一的区别确实是该子项的内容是该子项的文件夹索引或该子项的文件数据。注意：我在某种程度上简化了这个过程，但这很重要。
2. 索引文件将碎片化。如果碎片太多，您将无法将文件添加到该文件夹​​。这是因为允许的片段数有限制。这是设计使然。我已在支持事件电话中与Microsoft确认。因此，尽管理论上对一个文件夹中文件数量的限制是数十亿，但当您开始命中数千万个文件时，祝您好运，因为您首先会遇到碎片限制。
3. 然而，这还不是全部。您可以使用工具：contig.exe对该索引进行碎片整理。它不会减小索引的大小（对于数千万个文件，索引的大小最多可以达到几Gig），但是您可以减少碎片的数量。注意：“磁盘碎片整理”工具不会对文件夹的索引进行碎片整理。它将对文件数据进行碎片整理。仅contig.exe工具将对索引进行碎片整理。仅供参考：您还可以使用它来整理单个文件的数据。
4. 如果要进行碎片整理，请不要等到达到碎片限制的最大数目。我有一个无法整理碎片的文件夹，因为我已经等到为时已晚。我的下一个测试是尝试将一些文件从该文件夹移到另一个文件夹，以查看是否可以对其进行碎片整理。如果失败，那么我要做的是1）创建一个新文件夹。2）将一批文件移到新文件夹中。3）整理新文件夹的碎片。重复＃2＆＃3直到完成此操作，然后4）删除旧文件夹并重命名新文件夹以匹配旧文件夹。

要更直接地回答您的问题：如果您要查看100K条目，请不用担心。去把自己撞倒。如果您正在查看数千万个条目，则可以：

a）计划将它们细分为多个子文件夹（例如，假设您有100M个文件。最好将它们存储在1000个文件夹中，这样每个文件夹中只有100,000个文件比将它们存储到1个大文件夹中更好。）将创建1000个文件夹索引，而不是单个较大的索引，而该索引更可能达到最大碎片数限制或

b）制定计划定期运行contig.exe，以确保对大文件夹的索引进行碎片整理。

仅在无聊的情况下阅读以下内容。

实际的限制不是在片段的数目上，而是在存储指向该片段的指针的数据段的记录数上。

因此，您所拥有的是一个数据段，其中存储了指向目录数据片段的指针。目录数据存储有关目录应该存储的子目录和子文件的信息。实际上，目录不会“存储”任何内容。由于存储介质本身是线性的，它只是一种跟踪和呈现功能，向用户呈现层次结构的错觉。

短文件名创建还会导致性能问题，从而降低速度。如果文件夹中有超过30万个文件，Microsoft建议关闭短文件名创建功能[1]。前6个字符的唯一性越少，这就越成问题。

[1] 如何从http://technet.microsoft.com获得NTFS的工作原理，搜索“ 300,000”

我正在构建一个文件结构来容纳多达20亿（2 ^ 32）个文件，并执行了以下测试，这些测试显示，固态硬盘上每个NTFS目录的“导航+读取”性能急剧下降，大约为250个文件或120个目录。 SSD）：

• 在250至1000个文件之间，文件性能下降了50％。
• 目录性能在120至1000个目录之间下降了60％。
• 数字> 1000的值保持相对稳定

有趣的是，目录和文件的数量不会显着干扰。

因此，教训是：

• 大于250的文件号成本是2的倍数
• 120以上的目录的成本系数为2.5
• Windows 7中的File-Explorer可以处理较大的#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

这是测试代码：

[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; 
}

100,000应该罚款。

我（偶然地）看到人们在处理数百万个文件时遇到了问题，而我自己在Explorer中也遇到了问题，只是不知道如何计算超过60千个文件，但是NTFS应该适合您正在谈论的卷。

如果您想知道，技术（并且希望是理论上）的最大文件数为：4,294,967,295

对于本地访问，似乎不存在大量目录/文件。但是，如果您通过网络访问它，则经过数百次访问后，性能就会受到明显影响（尤其是从Vista机器访问时（从XP到Windows Server w / NTFS，在这方面运行起来似乎要快得多））。

创建具有N个条目的文件夹时，将在文件系统级别创建N个项目的列表。此列表是系统范围的共享数据结构。如果您随后开始通过添加/删除条目来连续修改此列表，则我希望对共享数据至少有一些锁争用。从理论上讲，这种争用会对性能产生负面影响。

对于只读方案，我无法想象有大量条目的目录性能下降的任何原因。

复制一个在线库时，我在目录中的NTFS上大约有10万个文件（每个数MB）的实际经验。

使用Explorer或7-zip打开目录大约需要15分钟。

winhttrack一段时间后，用编写站点副本总是会卡住。它也处理目录，其中包含约1 000 000个文件。我认为最糟糕的是，MFT只能按顺序遍历。

在ext3的ext2fsd下打开相同的文件，几乎得到了相同的时间。可能迁移到reiserfs（而不是reiser4fs）会有所帮助。

试图避免这种情况可能是最好的。

对于使用不带blob的程序，任何fs可能都是有益的。这就是Facebook存储照片的方式。