NTFS 性能不佳

Question

为什么 NTFS 性能与 Linux/ext3 等相比如此糟糕？我经常在从 Subversion 检出（大型）源代码树时看到这一点。在 NTFS 上结帐大约需要 10-15 分钟，而在 Linux（在几乎相同的硬件上）上的相应结帐需要快一个数量级（1-1.5 分钟）。

也许这是特定于处理大量小文件而 NTFS 在处理大文件时更好，但为什么会这样呢？一般来说，提高小文件的 NTFS 性能对 Windows 性能不是非常有益吗？

编辑：这并不意味着“与 ext3 相比，NTFS 很糟糕”的煽动性问题；我真正感兴趣的是为什么NTFS 在某些情况下表现不佳。这只是糟糕的设计（我怀疑），还是有其他问题起作用？

Answer 1

NTFS 有一个叫做Master File Table 的东西。当你读到它时，听起来真的很酷。

您可以看到 ext3 可以正常使用大约 95% 的磁盘，而 MFT 的存在意味着 NTFS 并不真的希望您使用超过 90% 的磁盘。但是我假设这不是您的问题，您的问题在于对许多小文件的许多操作。

这里的区别之一是创建小文件时会发生什么。如果文件小于块大小，则不会将其写入自己的块，而是存储在 MFT 中。如果文件完全保持创建时的状态，这很好。但是在实践中，这意味着当 svn 接触一个文件来创建它，然后添加到该文件中，从中删除，或者只是修改它不足以将它移动到它自己的块中，操作非常慢。此外，仅仅读取大量小文件会给它们所在的 MFT 带来一些压力，每个块都有多个。为什么要这样做？它先发制人地避免碎片化并更有效地使用更多的块，总的来说这是一件好事。

相比之下，在 ext2 和 3 中，每个文件的文件块都存储在它们所在目录的目录元数据旁边（如果可能，如果您的磁盘没有碎片并且您有大约 20% 的可用空间）。这意味着当 svn 打开目录时，许多块基本上免费缓存在驱动器上的 16mb 缓存中，然后再次缓存在内核缓存中。这些文件可能包括 .svn 文件和上次更新的修订文件。这很方便，因为这些可能是 svn 下一步要查看的一些文件。NTFS 无法做到这一点，尽管 MFT 的大部分应该缓存在系统中，但它们可能不是您接下来想要的部分。

Answer 2

嗯，你的特殊问题是因为

1. Subversion 本身来自 UNIX 世界，因此 Windows 版本具有类似的性能特征。
2. NTFS 性能对于数以万计的小文件来说确实不是很好。

您所看到的只是为特定操作系统设计的产品，并在该操作系统上进行了性能假设。当带到其他系统时，这通常会严重崩溃。其他示例是分叉与线程。在类 UNIX 上，并行化某些东西的传统方法只是生成另一个进程。在 Windows 上，进程的启动时间至少要长五倍，这是一个非常糟糕的主意。

一般而言，您不能仅仅将特定操作系统的任何工件授予具有截然不同架构的任何其他操作系统。也不要忘记，NTFS 具有许多文件系统功能，这些功能在当时广泛使用的 UNIX 文件系统中是不存在的，例如日志记录和 ACL。这些东西是有代价的。

有一天，当我有很多空闲时间时，我计划编写一个 SVN 文件系统模块，它利用您在 NTFS 上的功能，例如事务支持（应该消除“触及数百万个小文件的问题”）和备用数据流（应该消除对单独.svn目录的需要）。拥有它会是一件好事，但我怀疑 SVN 开发人员会在可预见的未来绕过实现这些东西。

旁注：我正在使用的大型 SVN 存储库上的一次更新需要大约 250,000 次文件操作。一些微小的声音告诉我，这对于 24 个更改的文件来说真的很重要......