为什么 NTFS 的性能与 Linux/ext3 等相比如此糟糕？我最常看到这种情况是在从 Subversion 签出（大型）源代码树时。在 NTFS 上签出大约需要 10-15 分钟，而在 Linux 上（在几乎相同的硬件上）相应的签出需要快一个数量级（1 - 1.5 分钟）。
也许这仅适用于处理大量小文件，而 NTFS 在处理大文件时效果更佳，但为什么会这样呢？提高 NTFS 在小文件方面的性能难道不会对 Windows 整体性能产生巨大益处吗？
编辑：这并不是一个“NTFS 与 ext3 相比很糟糕”的煽动性问题；我真正感兴趣的是为什么NTFS 在某些情况下性能不佳。这仅仅是设计不佳（我对此表示怀疑），还是还有其他问题？
答案1
NTFS 有一个东西叫主文件表。读起来真的很酷。
您可以看到，ext3 在磁盘使用率达到 95% 左右时表现良好，而 MFT 的存在意味着 NTFS 并不希望您使用超过 90% 的磁盘。但我认为这不是您的问题，您的问题在于对许多小文件进行的许多操作。
这里的一个区别是当您创建一个小文件时会发生什么。如果文件小于块大小，则不会将其写入其自己的块，而是存储在 MFT 中。如果文件保持与创建时完全相同的状态，那么这很好。但在实践中，这意味着当 svn 接触文件以创建它，然后向该文件添加内容、从中删除内容或仅对其进行修改（但不足以将其移动到其自己的块中）时，操作会非常慢。此外，仅读取大量小文件就会对它们所在的 MFT 造成一些压力，每个块中有多个小文件。为什么要这样做？这是先发制人地避免碎片并更有效地使用更多块，总的来说这是一件好事。
相比之下，在 ext2 和 3 中，每个文件的文件块都存储在其所在目录的目录元数据旁边（如果可能，如果您的磁盘没有碎片，并且有大约 20% 的可用空间）。这意味着当 svn 打开目录时，一些块基本上会免费缓存在驱动器上的 16mb 缓存中，然后再次缓存在内核的缓存中。这些文件可能包括 .svn 文件和上次更新的修订文件。这很方便，因为这些可能是 svn 接下来要查看的一些文件。NTFS 无法执行此操作，尽管 MFT 的大部分应该缓存在系统中，但它们可能不是您接下来想要的部分。
答案2
嗯，你的问题是因为
- Subversion 本身来自 UNIX 世界，因此 Windows 版本具有类似的性能特征。
- 对于大量小文件来说，NTFS 的性能确实不太好。
您所看到的只是为特定操作系统设计的产物，其性能假设在该操作系统上。当将其应用到其他系统时，通常会出现严重问题。其他示例包括分叉与线程。在类 UNIX 上，并行化某些东西的传统方式只是生成另一个进程。在 Windows 上，进程的启动时间至少是 Windows 的五倍，因此这确实是一个糟糕的想法。
一般来说，你不能将某个操作系统的任何特性应用到架构截然不同的操作系统上。另外，不要忘记 NTFS 具有许多当时广泛使用的 UNIX 文件系统所不具备的文件系统功能，例如日志记录和 ACL。这些功能是有代价的。
有一天，当我有很多空闲时间时，我计划编写一个 SVN 文件系统模块，利用 NTFS 上的功能，例如事务支持（应该可以消除“触及数百万个小文件的问题”）和备用数据流（应该可以消除单独.svn目录的需要）。这将是件好事，但我怀疑 SVN 开发人员在可预见的未来能否实现这些功能。
边注：我使用的大型 SVN 存储库的一次更新大约需要 250,000 个文件操作。一些微小的声音告诉我，对于更改了 24 个文件来说，这确实太多了...
答案3
这是微软的信息关于 NTFS 的工作原理。这可能超出了您的预期，但研究它可能会让您了解 NTFS 在哪些场景下存在问题。