ReFS 和 NTFS 的集群大小建议

IO放大:

IO 放大是指一个 IO 操作触发其他 IO 操作的广泛情况。, 无意的 IO 操作. 虽然看起来可能只发生了一次 IO 操作, 现实中, 文件系统必须执行多个 IO 操作才能成功服务初始 IO. 当考虑到文件系统无法再进行的各种优化时，这种现象的成本可能特别高:

当执行写操作时, 文件系统可以在内存中执行此写入，并在适当的时候将此写入刷新到物理存储.
某些写入, 然而, 可以强制文件系统执行额外的 IO 操作, 例如读取已经写入存储设备的数据. 从存储设备读取数据会显着延迟原始写入的完成, 因为文件系统必须等到从存储中检索到适当的数据后再进行写入.

ReFS 集群大小:

ReFS 提供 4K 和 64K 集群. 4K 是 ReFS 的默认集群大小, 和 我们建议大多数 ReFS 部署使用 4K 集群大小 因为它有助于减少昂贵的 IO 放大:

此外, 4K群集尺寸提供了与Hyper-V IO粒度更大的兼容性, 因此，我们强烈建议在REF上使用Hyper-V使用4K群集大小。与大型合作时，64k群集适用, 顺序IO, 但除此之外, 4K 应该是默认的簇大小.

NTFS 簇大小:

NTFS 提供的簇大小从 512 至 64K, 但总的来说, 我们建议 NTFS 上的簇大小为 4K, 因为 4K 集群有助于最大限度地减少存储小文件时浪费的空间. 我们还强烈建议不要使用小于 4K 的簇大小. 有两种情况, 然而, 64K 簇可能比较合适:

4K个簇限制最大卷和文件大小为16TB
64K 簇大小可以提供更大的卷和文件容量, 如果您在 NTFS 卷上托管大型部署，这是相关的, 例如托管 VHD 或 SQL 部署.
NTFS有碎片限制, 更大的簇大小可以帮助降低达到此限制的可能性
因为NTFS是向后兼容的, 它必须使用未针对现代存储需求进行优化的内部结构. 因此, NTFS 中的元数据可防止任何文件拥有超过约 150 万个范围.
一个可以, 然而, 使用“format /L”选项将碎片限制增加到约 600 万.
64K 集群部署不太容易受到这种碎片限制的影响, 因此，如果 NTFS 碎片限制存在问题，64K 集群是更好的选择. (数据删除, 稀疏文件, SQL 部署可能会导致高度碎片化。)
NTFS 压缩仅适用于 4K 簇, 因此在使用 NTFS 压缩时不适合使用 64K 簇. 考虑增加碎片限制, 如前面的项目符号中所述.

虽然 4K 簇大小是 NTFS 的默认设置, 在很多情况下 64K 簇大小是有意义的, 例如: Hyper-V, SQL, 重复数据删除, 或者当卷上的大多数文件都很大时.