ReFS 和 NTFS 的集群大小建议
IO放大:
IO 放大是指一个 IO 操作触发其他 IO 操作的广泛情况。, 无意的 IO 操作. 虽然看起来可能只发生了一次 IO 操作, 事实上, 文件系统必须执行多个 IO 操作才能成功服务初始 IO. 当考虑到文件系统无法再进行的各种优化时,这种现象的代价可能特别高:
- 当执行写操作时, 文件系统可以在内存中执行此写入,并在适当的时候将此写入刷新到物理存储.
- 某些写入, 然而, 可以强制文件系统执行额外的 IO 操作, 例如读取已经写入存储设备的数据. 从存储设备读取数据会显着延迟原始写入的完成, 因为文件系统必须等到从存储中检索到适当的数据后再进行写入.
ReFS 集群大小:
ReFS 提供 4K 和 64K 集群. 4K 是 ReFS 的默认集群大小, 和 我们建议大多数 ReFS 部署使用 4K 集群大小 因为它有助于减少昂贵的 IO 放大:
- 一般来说, 如果簇大小超过IO大小, 某些工作流程可能会触发意外 IO 的发生. 考虑以下场景,其中 ReFS 卷格式化为 64K 集群
- 通过选择 4K 集群而不是 64K 集群, 可以减少小于集群大小的 IO 数量, 防止频繁发生代价高昂的 IO 放大.
此外, 4K 集群大小提供与 Hyper-V IO 粒度的更好兼容性, 因此,我们强烈建议在 ReFS 上使用 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 簇大小是有意义的, 例如: 超V, SQL, 重复数据删除, 或者当卷上的大多数文件都很大时.