pet*_*mag 5 windows performance ntfs filesystems ext3
[从我的Ask HN 帖子交叉发布。如果问题对超级用户来说太宽泛，请随时关闭它。]
这是我多年来一直好奇的事情，但我从来没有找到关于这个话题的任何好的讨论。当然，我的 Google-fu 可能只是让我失望...
我经常处理涉及数千个相对较小文件的项目。这意味着我经常对所有这些文件或其中的很大一部分执行操作——将项目文件夹复制到别处、删除一堆临时文件等。在我多年来工作的所有机器中，我我们注意到 NTFS 处理这些任务的速度始终比 Mac 上的 HFS 或 Linux 机器上的 ext3/ext4 慢。但是，据我所知，NTFS 上的原始吞吐量实际上并没有变慢（至少不显着），但是每个文件之间的延迟只是稍微长了一点。对于数千个文件来说，这个小小的延迟确实加起来了。
（旁注：根据我的阅读，这是 git 在 Windows 上如此痛苦的原因之一，因为它的对象数据库非常依赖于文件系统。）
诚然，我的证据只是轶事——我目前没有任何真实的性能数据，但我很想进一步测试它（也许 Mac 双启动到 Windows）。尽管如此，我的极客坚持认为已经有人这样做了。
任何人都可以解释这一点，或者指出我自己进一步研究的正确方向？
小智 3
我不是 HFS 专家，但我研究过 NTFS 和 ext3 文件系统。听起来你应该考虑两件事。
首先，ext2/3/4 文件系统在磁盘上预先分配用于存储文件元数据（权限、所有权、构成文件数据的块或范围）的区域。我不认为 NTFS 可以。$MFT 记录相当于 ext3“inode”。据我了解，创建文件时 $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 是否将“目录”与“索引节点”与“文件数据”分开来仔细检查我的猜测。如果确实如此，那可能是一个很大的暗示。