文章

Windows ReFS 深度解析：下一代弹性文件系统的特性、实战与局限

本文深度剖析 Windows ReFS（Resilient File System）的设计理念与核心特性，包括完整性流、数据清理、虚拟块克隆等关键技术，对比 NTFS 的差异与取舍，并提供从创建、管理到适用场景的完整实战指南。

发表于
作者 ppemo
18 分钟阅读
Windows ReFS 深度解析：下一代弹性文件系统的特性、实战与局限

引言：为什么需要一个新文件系统？

自 Windows NT 3.1 以来，NTFS (New Technology File System) 已经统治 Windows 生态超过 30 年。它稳定、成熟，承载了从个人桌面到企业服务器的海量工作负载。然而，随着数据规模爆炸式增长（从 GB 时代迈入 PB 时代）、存储硬件的多样化（SSD、NVMe、大容量 HDD），以及虚拟化与容器化对存储效率提出的苛刻要求，NTFS 的架构天花板逐渐显现：

  • 元数据膨胀：NTFS 的 MFT (Master File Table) 在海量小文件场景下性能急剧退化。
  • 缺乏内建数据完整性校验：NTFS 无法主动检测静默数据损坏 (Silent Data Corruption)，即所谓的 “Bit Rot”。
  • 在线操作能力有限：卷扩展尚可，但卷收缩、校验和验证等操作往往需要离线执行。
  • 虚拟化场景下的低效拷贝：虚拟机快照、差异磁盘等操作在 NTFS 上需要完整复制数据块。

ReFS (Resilient File System) 正是微软为应对这些挑战而设计的新一代文件系统。它首次随 Windows Server 2012 发布，定位为面向大规模数据集、高可用性场景的 “弹性” 文件系统。ReFS 并非要全面取代 NTFS，而是针对特定工作负载提供显著更优的解决方案。

ReFS 的设计哲学

ReFS 的核心设计围绕三个关键词：弹性 (Resilience)、可扩展性 (Scalability) 和 数据完整性 (Data Integrity)。

弹性：从架构层面抵御数据损坏

ReFS 最引人注目的特性是其内建的数据完整性校验机制。与 NTFS 依赖外部工具（如 chkdsk）进行事后修复不同，ReFS 通过以下机制在架构层面主动保护数据：

  1. 完整性流 (Integrity Streams)：ReFS 使用 B+ 树变体存储元数据，并为数据流引入了可选的校验和 (Checksum) 机制。当启用完整性流后，每次读取数据都会自动验证其校验和，发现不一致时立即触发修复流程。
  2. 校验和 (Checksum) 的全面覆盖：ReFS 对所有元数据（包括文件名、时间戳、安全描述符等）强制计算并存储校验和，而不仅仅是文件数据。
  3. 写时分配 (Allocate-on-Write)：ReFS 在修改数据时不会原地覆盖，而是分配新的物理位置写入更新后的数据，完成后才释放旧位置。这种 Copy-on-Write 语义确保了在写入过程中断电或崩溃时，原始数据不会被破坏。
  4. 无需 chkdsk：传统 NTFS 在意外断电后需要运行 chkdsk 来修复文件系统一致性，这个过程在大卷上可能耗时数小时。ReFS 通过事务化的元数据更新和写时分配语义，从根本上消除了对离线修复工具的依赖。

可扩展性：面向 PB 级数据集

ReFS 在设计上采用了 64 位文件 ID 和极度扁平化的命名空间，其理论上限极为慷慨：

指标ReFSNTFS
最大卷大小35 PB (2^50 字节)256 TB
最大文件大小35 PB256 TB
最大文件名长度255 个 Unicode 字符255 个 Unicode 字符
最大目录中文件数理论无限 (受限于卷大小)~43 亿 (受限于 MFT)

这些上限意味着 ReFS 在理论上可以支撑从个人 NAS 到企业级数据中心的任何规模的数据集，而不会在架构层面遇到瓶颈。

核心特性详解

1. 完整性流 (Integrity Streams)

完整性流是 ReFS 最核心的特性。启用后，ReFS 会为每个数据块计算一个校验和并存储在元数据中。每次读取数据时，文件系统会自动验证校验和，确保返回给应用程序的数据与当初写入时完全一致。

1
2
3
4
5

# 在 Windows 上通过 PowerShell 启用完整性流
Set-FileIntegrity -FileName "D:\VMs\test.vhdx" -Enable $true

# 验证状态
Get-FileIntegrity -FileName "D:\VMs\test.vhdx"

检测到损坏后的自动修复：

  • 如果 ReFS 部署在 Storage Spaces (Mirror 或 Parity) 之上，当完整性流检测到校验和不匹配时，会自动从镜像副本或奇偶校验数据中修复损坏的块，整个过程对应用程序完全透明。
  • 如果 ReFS 部署在普通磁盘上（无冗余），它只能检测到损坏并报告给应用程序，但无法自动修复。

2. 数据清理 (Data Scrubbing)

ReFS 会定期在后台执行数据清理 (Scrubbing)，主动扫描整个卷的数据块，验证其校验和。这个过程类似于 ZFS 的 scrub 操作：

  • 默认每 4 周自动执行一次。
  • 发现静默损坏时，如果有冗余（Mirror/Parity），会自动修复。
  • 可通过 PowerShell 手动触发：
1
2

# 手动触发 ReFS 数据清理
Repair-Volume -DriveLetter D -Scan

3. 虚拟块克隆 (Block Cloning)

虚拟块克隆是 ReFS 面向虚拟化和容器化场景的杀手级特性。它允许在不实际复制数据的情况下创建文件的逻辑副本——两个文件共享相同的物理数据块，直到其中一个被修改。

这类似于文件系统层面的 “Copy-on-Write 快照”：

1
2

# Robocopy 在 ReFS 上会自动利用块克隆
robocopy D:\VMs D:\VMs-Backup *.vhdx /J /COPYALL

实际应用场景：

  • Hyper-V 快照合并：在 NTFS 上，合并快照需要逐块复制数据，耗时与快照大小成正比。在 ReFS 上，合并操作几乎是瞬间完成的（秒级到分钟级），因为只需修改元数据指针。
  • 差异虚拟硬盘 (Differencing VHD)：创建差异磁盘不再需要复制父磁盘数据。
  • 容器镜像分层：Windows 容器镜像的层共享变得高效。

4. 实时层优化 (Real-Time Tier Optimization)

当 ReFS 部署在 Storage Spaces Direct (S2D) 的混合存储架构上（同时包含 SSD 和 HDD），ReFS 支持自动化的数据分层：

  • 性能层 (Performance Tier)：由 SSD 或 NVMe 组成，存放热数据和元数据。
  • 容量层 (Capacity Tier)：由大容量 HDD 组成，存放冷数据。
  • ReFS 会根据数据的访问频率，在两层之间自动迁移数据，实现容量与性能的平衡。

5. 加速的固定磁盘操作 (Accelerated Fixed VHDX Operations)

ReFS 对 Hyper-V 的固定大小虚拟硬盘 (Fixed VHDX) 提供了专门的优化：

操作NTFSReFS
创建固定大小 VHDX逐块写零，与大小成正比秒级完成（惰性分配）
扩展固定大小 VHDX需要移动数据秒级完成
合并检查点 (Checkpoint)逐块复制秒级（块克隆）

这意味着在 ReFS 上管理大型虚拟机时，运维效率会有质的飞跃。

ReFS vs NTFS：选择的智慧

ReFS 并非 NTFS 的全面升级替代品，而是在特定领域远超 NTFS 的专业化文件系统。理解两者的取舍至关重要。

ReFS 的优势场景

场景为什么选 ReFS
Hyper-V 虚拟机存储块克隆加速快照/合并，完整性流保护虚拟磁盘
大规模文件服务器64 位文件 ID、无 MFT 膨胀、自动数据清理
存储空间直连 (S2D)原生支持实时分层、镜像加速修复
备份归档 (Veeam/SCDPM)完整性流确保备份数据的长期可靠性
持续可用 (Continuously Available) 文件共享ReFS 是 SQL Server on S2D 的推荐文件系统

NTFS 的优势场景

场景为什么选 NTFS
系统盘 (C:)Windows 启动分区必须使用 NTFS
需要文件级加密 (EFS)ReFS 不支持 EFS
需要磁盘配额 (Disk Quotas)ReFS 不支持传统磁盘配额
需要硬链接 (Hard Links)ReFS 不支持硬链接
需要 Object IDReFS 不支持 Object ID
对性能极度敏感的随机小 I/ONTFS 在某些基准测试中仍有微弱优势

关键限制总结

以下是 ReFS 截至 Windows Server 2025 / Windows 11 24H2 的主要限制：

  • 不能用作系统启动盘：Windows 无法从 ReFS 卷启动。
  • 不支持 EFS 文件加密：需要使用 BitLocker 进行全卷加密。
  • 不支持磁盘配额：需要通过其他机制（如 FSRM）实现。
  • 不支持硬链接和对象 ID：部分依赖这些特性的应用程序无法在 ReFS 上运行。
  • 不支持 chkdsk 修复：损坏数据只能通过冗余自动修复或从备份恢复。
  • 压缩和稀疏文件支持有限：ReFS 在较新版本中开始支持，但功能不如 NTFS 完善。
  • 最小分配单元 (Cluster Size)：建议使用 64KB（NTFS 通常使用 4KB），小文件会浪费空间。

实战指南

创建 ReFS 卷

方法一：PowerShell（推荐）

1
2
3
4
5
6
7
8
9
10
11
12

# 1. 查看可用磁盘
Get-Disk

# 2. 初始化磁盘（假设磁盘编号为 3）
Initialize-Disk -Number 3 -PartitionStyle GPT

# 3. 创建分区并格式化为 ReFS
New-Partition -DiskNumber 3 -UseMaximumSize -DriveLetter D |
  Format-Volume -FileSystem ReFS -NewFileSystemLabel "Data-ReFS" -AllocationUnitSize 64KB

# 4. 验证
Get-Volume -DriveLetter D | Format-List FileSystem, AllocationUnitSize

方法二：磁盘管理 (diskmgmt.msc)

  1. 打开 “磁盘管理”。
  2. 右键目标磁盘 → “初始化磁盘” → 选择 GPT。
  3. 右键 “未分配” 空间 → “新建简单卷”。
  4. 在格式化界面中，文件系统选择 ReFS，分配单元大小选择 64KB。

在 Storage Spaces 上部署 ReFS（推荐方式）

ReFS 的真正威力在与 Storage Spaces 结合时才能完全发挥。以下是创建镜像存储空间的示例：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

# 1. 创建存储池
New-StoragePool -FriendlyName "MyPool" `
  -StorageSubsystemFriendlyName "Windows Storage*" `
  -PhysicalDisks (Get-PhysicalDisk -CanPool $true)

# 2. 创建虚拟磁盘（镜像，双副本）
New-VirtualDisk -StoragePoolFriendlyName "MyPool" `
  -FriendlyName "MirrorDisk" `
  -ResiliencySettingName Mirror `
  -NumberOfDataCopies 2 `
  -Size 1TB `
  -ProvisioningType Fixed

# 3. 初始化并格式化为 ReFS
Get-VirtualDisk -FriendlyName "MirrorDisk" |
  Get-Disk |
  Initialize-Disk -PartitionStyle GPT

Get-VirtualDisk -FriendlyName "MirrorDisk" |
  Get-Disk |
  Get-Partition |
  New-Partition -AssignDriveLetter |
  Format-Volume -FileSystem ReFS -AllocationUnitSize 64KB

# 4. 为关键数据启用完整性流
Set-FileIntegrity -FileName "D:\ImportantData" -Enable $true

监控与维护

1
2
3
4
5
6
7
8
9
10
11
12

# 查看 ReFS 卷状态
Get-Volume -DriveLetter D | Format-List *

# 查看文件完整性状态
Get-FileIntegrity -FileName "D:\VMs\server.vhdx"

# 手动触发数据清理
Repair-Volume -DriveLetter D -Scan

# 查看 ReFS 事件日志
Get-WinEvent -LogName "Microsoft-Windows-ReFS/Operational" -MaxEvents 20 |
  Format-Table TimeCreated, Id, Message -Wrap

从 NTFS 迁移到 ReFS

重要：ReFS 不支持从 NTFS 原地转换 (In-Place Conversion)。 迁移必须通过数据拷贝完成：

1
2
3
4
5
6
7

# 使用 Robocopy 迁移数据（推荐，支持 ReFS 块克隆优化）
robocopy E:\OldData D:\NewReFS-Data /E /J /COPYALL /R:3 /W:5 /MT:16 /LOG:C:\migration.log

# /E - 包含子目录（含空目录）
# /J - 使用无缓冲 I/O（大文件性能更佳）
# /COPYALL - 复制所有文件信息（属性、时间戳、安全描述符等）
# /MT:16 - 16 线程并发

性能考量

ReFS 的性能表现取决于工作负载类型：

  • 大文件顺序读写：ReFS 与 NTFS 性能相当，差异在误差范围内。
  • 小文件随机 I/O：NTFS 在某些场景下略有优势，因为 ReFS 的 B+ 树元数据结构开销略大。
  • 虚拟化场景：ReFS 通过块克隆和惰性分配，使得快照、合并、创建等操作的速度远超 NTFS。
  • 数据完整性验证：完整性流会引入约 2-5% 的 CPU 开销（用于计算校验和），但在现代硬件上几乎可以忽略。

微软官方在 SQL Server on Storage Spaces Direct 的场景中，推荐使用 ReFS 64KB 分配单元作为数据卷的最佳实践。

总结

ReFS 代表了 Windows 文件系统的进化方向——从被动的 “数据容器” 转变为主动的 “数据保护者”。它的完整性流、数据清理和写时分配机制，使得静默数据损坏不再是需要依赖运气来规避的风险，而是可以被系统性地检测和修复的问题。

然而，ReFS 并非万能钥匙。它不能用作系统盘，不支持 EFS 和硬链接，且在某些传统桌面场景下优势不明显。选择 ReFS 还是 NTFS，本质上是一个场景驱动的决策：

  • 虚拟化、大规模存储、数据完整性要求高 → ReFS
  • 系统盘、传统桌面应用、需要 EFS/硬链接 → NTFS

如果你的工作负载涉及 Hyper-V、Storage Spaces、大规模文件服务器或长期数据归档，ReFS 值得认真考虑。它的 “弹性” 不仅体现在名称上，更体现在对数据的每一个字节的守护中。

Windows, 存储
ReFS NTFS 文件系统 Windows Server Storage Spaces 数据完整性
本文由作者按照 CC BY 4.0 进行授权