[转载自我的询问HN帖子。如果问题对于超级用户来说太宽泛，请随意关闭它。]
多年来我一直对此感到好奇，但我从未找到有关该主题的任何良好讨论。当然，我的 Google 能力可能让我失望了...
我经常处理涉及数千个相对较小文件的项目。这意味着我经常对所有这些文件或其中的大部分文件执行操作 - 将项目文件夹复制到其他地方，删除一堆临时文件等。多年来，在我使用过的所有机器中，我注意到 NTFS 处理这些任务的速度始终比 Mac 上的 HFS 或 Linux 机器上的 ext3/ext4 慢。但是，据我所知，NTFS 上的原始吞吐量实际上并不慢（至少没有明显慢），但每个文件之间的延迟只是稍微长一点。对于数千个文件来说，这个小小的延迟确实很严重。
(旁注：据我所知，这是 git 在 Windows 上如此麻烦的原因之一，因为它的对象数据库严重依赖文件系统。)
当然，我的证据只是传闻——我目前没有任何实际性能数据，但我很想进一步测试（也许使用 Mac 双启动 Windows）。不过，我的极客精神坚持认为已经有人这样做了。
有人可以解释一下这一点吗，或者可以给我指出正确的方向以便我自己进一步研究它？
答案1
我不是 HFS 专家，但我研究过 NTFS 和 ext3 文件系统。听起来你应该考虑两件事。
首先，ext2/3/4 文件系统会预先分配磁盘上的区域来存储文件元数据（权限、所有权、构成文件数据的块或范围）。我认为 NTFS 不会这样做。ext3“inode”的等价物是 $MFT 记录。据我了解，创建文件时不一定已经分配了 $MFT 记录。如果需要，可以增加 $MFT。在 ext2/3/4 文件系统中增加 inode 数量要困难得多。
我不知道任何 NT 内部细节，但一切读起来都像 $MFT 记录是根据需要创建的，因此你可以将小文件、目录和大文件散布其中。
对于 BSD FFS 样式的文件系统（ext2/3/4 文件系统肯定是这样的），已经花了很多心思来对磁盘上的 inode 进行分组，并将目录文件与 inode 分开。已经花了很多心思来高效安全地写出目录和元数据。请参阅：http://www.ece.cmu.edu/~ganger/papers/softupdates.pdf举个例子。
其次，如果我没看错的话，小文件的数据保存在 $MFT 记录中。ext2/3/4 则不是这样，这就是为什么我上面提到小文件和大文件的处理方式略有不同。
在我看来，NT（操作系统）正在遭受 $MFT 争用。目录得到更新，这是 $MFT 记录更新。小文件被创建，这是 $MFT 更新。操作系统无法有效地排序读写，因为所有元数据更新和数据写入都转到同一个“文件”$MFT。
但是，就像我说的，这只是猜测。我对 NTFS 的了解主要来自阅读，只有很少一部分来自尝试。您可以通过查看 HFT 是否将“目录”与“inode”和“文件数据”分开来再次验证我的猜测。如果是，那可能是一个很大的提示。