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