![在 NTFS 上使用 2MB 的分配单元大小是不是一个坏主意?](https://linux22.com/image/1583406/%E5%9C%A8%20NTFS%20%E4%B8%8A%E4%BD%BF%E7%94%A8%202MB%20%E7%9A%84%E5%88%86%E9%85%8D%E5%8D%95%E5%85%83%E5%A4%A7%E5%B0%8F%E6%98%AF%E4%B8%8D%E6%98%AF%E4%B8%80%E4%B8%AA%E5%9D%8F%E4%B8%BB%E6%84%8F%EF%BC%9F.png)
它适用于仅包含虚拟机映像的 200GB 大小的驱动器。附加文件可能包括几个 xml 文件。映像本身的大小从 5GB 到 40GB 不等。
2MB 是好主意还是坏主意?逻辑表明,单位越大意味着需要跟踪的单位越少,但我是否应该注意性能损失?
我特别指的是虚拟机内部的性能下降,这是由于使用较小的 AUS 时会产生碎片。我有点希望较大的 AUS 意味着更少的寻道时间和略微提高的性能。
我正在使用 Win10,2M 是最大可用的 AUS 选项。
如果这个问题已经存在,我很抱歉。我找不到很多讨论超过 64K 单位的内容,我的单位是兆字节,我真的需要确认后才能继续。
答案1
簇大小越高意味着$Cluster
MFT 中的文件越小,并且需要更少的索引来跟踪卷中的数据。
这意味着磁盘空间增加了,但由于这已不再是 90 年代中期了,所以可能不值得 - 至少对于 200GB 的驱动器来说不值得。
就性能而言,如果数据倾向于按顺序访问(例如播放视频/音乐)或以集群大小为单位分块访问,则性能可能会略有改善或至少不受影响。
这可能不适用于虚拟机。如果 vmdk 的簇大小不是 2M,并且与磁盘簇不对齐,我认为较大的簇大小可能会损害随机访问,因为您要求 NTFS 加载 2M 的数据,而该扇区中可能只需要一个 4096 或 512 字节的块。
使用较新的“4K”格式硬盘时,您也面临类似的情况 - 它们在内部以 4096 字节块进行读取/写入,但仍允许操作系统请求 512 字节块。如果您的数据未按 4096 字节对齐,则许多请求都会出现重复读取。操作系统现在会对齐数据,因此您可能不需要考虑这个问题 - 但我想说的是,您上述使用虚拟机和更改集群大小的情况可能会产生类似的问题。
答案2
运行具有不同分配大小的基准测试后,我凭经验发现 4k 会给您带来最佳性能。这是因为现代硬盘上的实际扇区大小为 4k。我在 5TB 驱动器上使用最小 1GB 大小的文件进行了测试。
一般而言,如果集群大小超出 IO 大小,某些工作流可能会触发意外 IO。即使没有发生额外的 IO,您也不会从任何加速中受益,因为最终它会转化为实际磁盘上的 4k 最终写入或读取。
随着时间的推移,碎片可能会减少,但我假设您的驱动器是 SSD,因为它只有 200 GB,所以碎片并不是真正的问题。