NTFS 3.1 vs ReFS 3.9(Win11 22H2, 22621.2134 企业版)

1

Loading

声明:测试结果仅代表在下文所述的场景下。由于可变因素多种多样,单一场景下的测试结果不能代表全部。请辩证看待,欢迎讨论、提出意见和建议。

本文于 2023-9-9 在远景论坛首发。


多图杀猫,前面是测试平台和条件介绍,想看结论和数据(在最后)可以拉到下面倒着看。

1  测试平台

1.1  硬件平台

CPU Intel® Core™ i5-13400F
RAM Hynix A-die 2×32GB DDR5-6600 CL38
主板 ASRock Z790 PG-ITX/TB4 (BIOS v7.03)
硬盘 Intel® Optane™ SSD 900P 280GB U.2(系统盘)
Intel®/Solidigm SSD D7-P5620 6.4TB U.2 (测试盘)
Intel®/Solidigm SSD D7-P5620 6.4TB U.2
电源 ASUS ROG Loki SFX-L 1000W
  • 系统盘连接在主板 M2_2 接口(PCI-E 4.0 x4, PCH 桥接),实际运行在 PCI-E 3.0 x4
  • 测试盘连接在主板 M2_3 接口(PCI-E 4.0 x4, PCH 桥接),实际运行在 PCI-E 4.0 x4
  • 另有一块盘连接在主板 M2_1 接口(PCI-E 4.0 x4, CPU 直连),实际运行在 PCI-E 4.0 x4。

系统盘和测试盘均使用 Intel® Optane™ SSD 900P 包装内原配的 M.2 to U.2 转接线(安费诺代工)连接,此转接线口碑较好,对 Intel SSD 兼容性佳,且可运行在 PCI-E 4.0 x4 模式下。

另一块盘使用 LinkReal M.2 to SFF-8654 4i 转接卡 + SFF-8654 4i to SFF-8639 (U.2) 转接线(立讯精密代工)连接,此转接线针对 PCI-E 4.0 信号设计,且卖家 / 其他买家(使用 KIOXIA CD6)/ 我均已测试,可以正常使用,性能无损耗

 

1.2  软件平台

Microsoft Windows 11 企业版 x64 22H2 (22621.2134)

CrystalDiskMark 8.0.4 x64(Microsoft Store)

IOMeter 1.1.0

未使用 AS SSD Benchmark,原因为已多次看到有人对该软件在近几年 SSD 性能大幅提升背景下的结果可靠性提出质疑。


2  测试条件

2.1  环境和基础设置

测试时室温 25.5℃,所有风扇满转速,SSD 温度控制在 50 ℃ 以内,其他硬件也均在正常温度范围内,未触发性能限制。

测试盘根据 Intel 测试标准,设置在 Power Mode 0 (25W),也就是最高性能模式。

LBA Format 设置为 4K Native,即逻辑扇区、物理扇区均为 4096 Bytes

测试前确保硬盘空闲 5 分钟以上。

2.2  文件系统设置

关闭快速格式化,能够尽可能保证 SSD 是“干净”的,降低对性能测试的影响。

使用 计算机管理 – 磁盘管理 建立大小为 3.2TB(硬盘容量的一半)的分区并格式化,分配单元大小 4096(与物理扇区、逻辑扇区大小一致)。

对 NTFS,不开启压缩功能。对 ReFS,关闭 / 开启 完整性流 (File Integrity) 均做测试。

NTFS:


ReFS File-Integrity Off:

ReFS File-Integrity On:

2.3  测试条件限制

  1. 系统不是全新安装的,但尽可能关闭了所有无关程序(包括 Windows Defender)。
  2. ASRock Z790 PG-ITX/TB4 的三个 M.2 插槽转接 U.2 使用时,均存在 PCI-E 4.0 信号完整性问题(或兼容性问题,或 BIOS 问题等),会导致 4KiB 随机读写性能偏低(表现为偶发高延迟拉低平均性能)。PCI-E 3.0 模式不存在该问题,但未找到指定 PCI-E 协议版本的方法。
  3. 由于在正常使用的电脑上测试,没有条件将测试盘接入 CPU 直连插槽(A4 结构 ITX 机箱,需要拆除几乎所有硬件),也没有条件使用全新 / 全空的硬盘测试。故采用拆出一个 50% 容量分区的办法,并将另一有数据的分区完全卸载,尽量降低影响。
  4. 出于稳定性考虑,使用的是 RTM 系统(即正式版),仅支持 ReFS 3.9,而非论坛广泛讨论的 ReFS 3.10。不过“4K 性能提升 50%”的说法来源于多年前,所以我认为“性能提升”并非来源于 ReFS 3.10
  5. 数据中心级 SSD 没有 SLC Cache 模拟,性能可能较消费级旗舰 PCI-E 4.0 SSD 低(尤其是低队列深度、单线程的场景)。但同样,数据中心级 SSD 在各种条件下都具有出色的性能一致性,可以一定程度上降低误差。

3  测试项目与结果

为提升结果可信度,测试顺序为 NTFS – ReFS – NTFS(复测)- ReFS(复测)– ReFS(开启 File Integrity),每次均重新格式化

3.1  CrystalDiskMark

使用 5 次循环、32 GiB 跨度的测试模式。

3.1.1  NTFS

默认设置:

NVMe SSD 设置:

3.1.2  ReFS 完整性流关闭

默认设置:

NVMe SSD 设置:

3.1.3  ReFS 完整性流开启

默认设置:

NVMe SSD 设置:

3.2  IOMeter
(未测试 ReFS File Integrity ON 场景)

基于 Intel 官方提供的测试方案微调。

4KiB 读取:QD32 × 8 Workers  /  4KiB 写入:QD64 × 4 Workers

每个 Worker 使用 8,388,608 扇区 (32GiB) 跨度(Worker 间共享相同跨度),32 Outstanding I/Os.

固定随机种子 8664,测试时长为 1 分钟。

3.2.1  NTFS

吞吐量 & 响应时间:

平均 963.87 MB/s  @ 0.54 ms;平均 2039.46 MB/s  @ 0.37 ms.

响应时间分布:

3.2.2  ReFS 完整性流关闭

吞吐量 & 响应时间:


平均 817.10 MB/s  @ 0.57 ms;平均 1882.00 MB/s  @ 0.55 ms.

响应时间分布:

3.3  汇总与对比

3.1.1  NTFS vs ReFS 完整性流关闭

CrystalDiskMark:

Read MB/s Write MB/s R70%W30%Mix MB/s
NTFS ReFS Rel. % NTFS ReFS Rel. % NTFS ReFS Rel. %
SEQ1M Q8T1

7004.33

5090.31

-27.33%

4496.85

4413.45

-1.85%

6170.44

4783.16

-22.48%

SEQ1M Q1T1

2698.67

828.33

-69.31%

4443.71

4086.92

-8.03%

1923.22

1095.15

-43.06%

SEQ128K Q32T1

6982.35

4018.87

-42.44%

4469.24

4265.21

-4.57%

5168.52

4461.9

-13.67%

RND4K Q32T16

2039.53

2125.66

+4.22%

1989.02

1816.62

-8.67%

2112.8

2126.94

+0.67%

RND4K Q32T1

558.02

492.51

-11.74%

411.47

360.8

-12.31%

494.53

436.67

-11.70%

RND4K Q1T1

43.42

43.28

-0.32%

205.26

118.99

-42.03%

60.09

53.15

-11.55%

ReFS 对比 NTFS 基本是全面落败,且部分项目的落后幅度相当夸张。ReFS 仅在多线程、高队列深度的 4K 随机读取 / 七读三写存在微弱优势。这倒是比较符合现在的 ReFS 为数据中心而生的特点。

IOMeter:

ReFS 再度稳定落后,写入吞吐量落后 NTFS 15.23%,延迟高了 4.16%;读取吞吐量落后好一些,约 7.23%,但延迟高出 50% 之多,非常夸张了。

3.1.2  ReFS 完整性流关闭 vs ReFS 完整性流开启

CrystalDiskMark:

Read MB/s

Write MB/s

R70%W30%Mix MB/s

OFF

ON

Rel. %

OFF

ON

Rel. %

OFF

ON

Rel. %

SEQ1M Q8T1

5090.31

4332.61

-14.89%

4413.45

4413.02

-0.01%

4783.16

3809.7

-20.35%

SEQ1M Q1T1

828.33

687.7

-16.98%

4086.92

2862.24

-29.97%

1095.15

549.62

-49.81%

SEQ128K Q32T1

4018.87

3828.33

-4.74%

4265.21

3933.9

-7.77%

4461.9

1384.39

-68.97%

RND4K Q32T16

2125.66

1673.81

-21.26%

1816.62

1146.18

-36.91%

2126.94

1467.68

-31.00%

RND4K Q32T1

492.51

313.09

-36.43%

360.8

225.28

-37.56%

436.67

276.05

-36.78%

RND4K Q1T1

43.28

42.95

-0.76%

118.99

104.72

-11.99%

53.15

53.45

+0.56%

CRC 算法对文件数据的介入,让开启了完整性流的 ReFS 意料之中地出现了性能下降,但如此下降幅度之大,还是有些出乎意料。

微软是这样描述完整性流的性能损失的:

尽管完整性流为系统提供更大的数据完整性,但它也会产生性能成本。 这有几种不同的原因:

  • 如果启用了完整性流,则所有写入操作都将成为写时分配操作。 尽管这避免了任何读取-修改-写入瓶颈,但由于 ReFS 不需要读取或修改任何现有数据,因此文件数据经常会变得碎片化,从而使读取延迟。
  • 根据系统的工作负载和基础存储,计算和验证校验和的计算成本可能会导致 IO 延迟增加。

由于完整性流会带来性能成本,因此建议在性能敏感系统上禁用完整性流。

 


4  结论

基于以上测试结果,我的结论是:当前完全不建议个人用户使用 ReFS

我认为当前 ReFS 性能降低的幅度已经达到了人可以感知的程度,会带来可闻的体验下降。

诚然,ReFS 对元数据进行校验的特性,理论上使它具备了比 NTFS 更好的数据安全性。但 NTFS 的安全性其实也不差,大部分情况下 chkdsk 也都能恢复损坏的数据。并且,得益于微软在操作系统层面对 NTFS 的不断优化,其健壮性和性能都在不断提升,更重要的,NTFS 是久经考验的文件系统,已经被普及并广泛使用了近 20 年,巨量的工具支持和完善的生态也是非常重要的。

也正是校验的特性,使 ReFS 必然存在容量和性能开销:需要额外的空间来存储校验数据,额外的时间来计算校验值、写入和读取校验数据。良好的优化,抑或是深度软硬件结合(SSD 主控和 CPU)可以尽可能降低这部分开销,但截至 ReFS 3.9,优化显然是不到位的。

格式化为 ReFS 的功能在某个时间节点被微软从 Windows 10/11 非企业版(专业工作站版)RTM 中移除,显然微软也是认为 ReFS 还没有那么适合普通用户使用。不过既然 ReFS 已经在 Windows Insider Preview 版本中回归,并且加入了大量新特性,或许有一天 ReFS 会回归 RTM,甚至取代 NTFS,实现微软最初的梦想。

再说点个人向的话吧。我在使用 NTFS 的时候,遇到过数据损坏、数据丢失、误删分区等等情况,但绝大多数情况下,都能通过 chkdsk,或者 EasyRecovery、DiskGenius 之类的软件成功挽救,而支持 ReFS 的工具至今寥寥无几,即使支持,也不如 NTFS 支持得完善。

一年前我还在用 Windows 10 LTSC 2021,用两块 SATA SSD 组成存储空间,并建立了一个 ReFS 格式的镜像卷(可认为是软件 RAID 1),这种用法是 ReFS 目前主攻的方向。然而当我在这个分区安装 SolidWorks 的时候,安装程序卡死了,整个系统运行得也非常缓慢,甚至无法正常关机(没反应);其他程序只要访问这个 ReFS 分区,就会和安装程序一样卡死。后来想尽各种办法终于解决了问题(删干净了 SolidWorks),但再也不能向内复制文件了。用 ReFS Util 修复无果,第三方软件愣是没找到能用的。后来分析,猜测是 SolidWorks 安装了字体文件到 ReFS 分区,而字体文件会随 Windows 启动加载,进而导致问题。可想而知,基于 21H2 的 LTSC 2021,其 ReFS 功能并不完善,很可能在这种特殊场景下产生了 bug。当然现在 Canary 的 ReFS 都能装系统了,应该这个 bug 也被修复了吧。

感谢耐心阅读到这里,祝大家生活愉快!