NTFS性能不佳

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

也许这是特定于处理许多小文件的，而NTFS在处理大文件时会更好，但是为什么要这样呢？通常，提高小文件的NTFS性能是否会对Windows性能产生巨大的好处？

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

NTFS拥有一个称为“ 主文件表”的东西。当您阅读有关内容时，它听起来真的很酷。

您可以看到ext3最多可以执行约95％的磁盘使用，而MFT的存在意味着NTFS确实不希望您使用超过90％的磁盘。但是我将假定这不是您的问题，并且您的问题是许多小文件上的许多操作。

这里的区别之一是创建一个小文件时会发生什么。如果文件小于块大小，则不会将其写入自己的块，而是存储在MFT中。如果文件保持创建时的原样，这很好。但是在实践中，这意味着当svn触摸文件来创建文件，然后将其添加到该文件，从该文件中删除或仅通过对其进行修改（不足以将其移动到其自身的块中）时，该操作相当缓慢。同样，仅读取大量小文件也会对它们全部驻留的MFT造成一定的压力，每个块有多个。为什么要这样做？它可以避免碎片，并更有效地使用更多块，这通常是一件好事。

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

好吧，您的特定问题是因为

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

您所看到的只是为特定操作系统设计的工件的产物，并具有该操作系统的性能假设。当带到其他系统时，这通常会严重崩溃。其他例子是分叉与线程。在类似UNIX的系统上，使某事物并行化的传统方法只是产生另一个进程。在Windows上，至少需要花费五倍的时间才能启动进程，所以这确实是个坏主意。

通常，您不能仅仅将某个特定操作系统的任何工件授予在具有截然不同的体系结构的任何其他工件上。同样不要忘记，NTFS具有当时广泛使用的UNIX文件系统所缺少的许多文件系统功能，例如日志和ACL。这些事情是有代价的。

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

旁注：我正在使用的大型SVN存储库上的一次更新进行了大约250,000个文件操作。微小的声音告诉我，对于24个已更改的文件，这确实是很多...

这是Microsoft 有关NTFS工作原理的信息。对于您正在寻找的内容，这可能是过大的选择，但对其进行研究，可能会发现NTFS存在问题的情况。