Question

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

在遇到性能问题或其他问题之前，是否有关于可以放在单个目录中的文件或目录限制的指导？

E.g。有一个包含100,000个文件夹的文件夹，这是一件好事吗？

Answer 1

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

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

更直接地回答您的问题：如果您正在查看100K条目，请不要担心。去敲你自己。如果你正在查看数以千万计的条目，那么：

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

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

只有在您感到无聊时才阅读以下内容。

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

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

Answer 2

短文件名创建也会降低性能问题。如果文件夹中有超过300k的文件，Microsoft建议关闭短文件名创建[1]。前6个字符的唯一性越小，问题就越多。

来自How NTFS Works的

[1] http://technet.microsoft.com，搜索“300,000”

Answer 3

我正在构建一个文件结构来托管多达20亿（2 ^ 32）个文件，并执行以下测试，显示导航+读取性能急剧下降，大约250个文件或每个NTFS目录上的120个目录State Drive（SSD）：

文件性能在250到1000个文件之间下降50％。
目录性能在120到1000个目录之间下降了60％。
数字值＆gt; 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; 
}

Answer 4

100,000应该没问题。

我（有趣地）看到人们遇到了数百万个文件的问题，我自己也遇到过问题，只是不知道如何计算过去60多万个文件，但NTFS应该对你的数量有好处。说再谈。

如果你想知道，技术（我希望理论）最大文件数是：4,294,967,295

Answer 5

对于本地访问，大量目录/文件似乎不是问题。但是，如果您通过网络访问它，那么在几百个之后就会出现明显的性能损失（尤其是从Vista计算机访问时（XP到Windows Server w / NTFS似乎在这方面运行得更快）。）

Answer 6

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

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

Answer 7

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

使用资源管理器或7-zip打开目录大约需要15分钟。

使用winhttrack编写网站副本将在一段时间后一直停滞不前。它还涉及目录，包含大约1 000 000个文件。我认为最糟糕的是MFT只能顺序遍历。

在ext3上的ext2fsd下打开相同的时间给出了几乎相同的时间。可能转向reiserfs（而不是reiser4fs）可以提供帮助。

尽量避免这种情况可能是最好的。

对于你自己的程序使用blob没有任何fs可能是有益的。这就是Facebook用来存储照片的方式。

NTFS性能和大量文件和目录

7 个答案: