Share via

为 Windows 构建下一代文件系统：ReFS

  • Article

我们希望通过介绍 Windows 8 中引入的下一代文件系统继续展开有关数据存储的话题。NTFS 是目前使用最为广泛、最先进、功能最丰富的文件系统，在众多领域得到了广泛应用。但每当我们重新设计 Windows 时，我们都不希望止步于过去的成功经验，因此，我们在 Windows 8 中也引入了一种经过精心设计的新文件系统。ReFS（弹性文件系统 (Resilient File System) 的缩写）是基于 NTFS 构建而成的，因此该文件系统除具有至关重要的兼容性外，还针对新一代存储技术和应用情境对架构和工程设计进行了调整。与引入每种文件系统时相同，在 Windows 8 中，ReFS 将仅作为 Windows Server 8 的一部分引入。当然，在应用程序级别，以 ReFS 格式存储的数据可以由客户端作为 NTFS 数据访问。当您阅读本博文时，请不要忘记 NTFS 目前仍是业内领先的 PC 文件系统技术。

这篇详细介绍该架构的博文有存储和文件系统团队的开发经理 Surendra Verma 撰写，与每项功能的开发相同，读者的反馈为我们提供了诸多帮助。在本博文的结尾处，我们再次添加了常见问题解答版块。
--Steven

备注：请继续通过 @buildwindows8 关注我们的动态，我们会通过该博客提供来自 CES 的一些更新。

在本博文中，我希望向您介绍一下 Windows 中新引入的文件系统。我们称之为 ReFS 的这种文件系统从头到脚都为针对所有不同的 Windows 部署方式满足用户多样化的需求而设计。

ReFS 的关键目标如下：

  • 保持对一部分广泛采用的 NTFS 功能的兼容性，同时放弃其他价值有限但会大幅增加系统复杂性和占用率的功能。
  • 验证并自动更正数据。数据可能会由于各种原因而损坏，因此必须对其进行验证，并在可能的情况下进行自动更正。元数据必须写入适当的位置，以避免出现“断写”，我们将在下文中详细介绍该情况。
  • 针对超大规模应用进行优化。使用普遍适用的可扩展结构。不要假设磁盘检查算法可以扩展到整个文件系统的规模。
  • 确保文件系统永不脱机。当出现损坏时，最佳的解决方案是隔离错误，并允许继续访问余下的卷，同时尽可能打捞所有可用的数据，并且这一切都通过实时的方式完成。
  • 借助与 ReFS 联合设计和构建的存储空间功能，提供完整的端到端弹性结构。

ReFS 的关键功能如下（请注意，其中某些功能与存储空间联合提供）。

  • 带有校验和的元数据完整性
  • 提供可选用户数据完整性的完整性流。
  • 通过写入时分配事务模型实现可靠的磁盘更新（也称为写入时复制）
  • 支持超大规模的卷、文件和目录
  • 存储池和虚拟化使得文件系统可建立并易于管理
  • 通过数据条带化提高性能（带宽可管理）并通过备份提高容错性
  • 通过磁盘扫描防止潜在的磁盘错误
  • 借助“数据打捞”实现损坏还原，以便在任何情况下尽可能提高卷的可用性
  • 跨计算机共享存储池，以提供额外的容错性和负载平衡

此外，ReFS 还从 NTFS 集成了某些功能和语义，包括 BitLocker 加密、用于安全的访问控制列表、USN 日志、更改通知、符号链接、交接点、装入点、重解析点、卷快照、文件 ID 和操作锁。

当然，客户端只要使用任何操作系统中可访问现有 NTFS 卷的文件访问 API，就可以访问以 ReFS 存储的数据。

关键设计属性和功能

我们的设计属性与我们的目标密切相关。在我们逐一介绍这些属性的同时，请时刻记住我们的文件系统会由数亿台不同的设备使用，规模从体积最小的计算机到最大的数据中心，从最小的存储格式到最大的多轴格式，从固体状态存储到最大的驱动器和存储系统。同时，Windows 文件系统会由来源各异的各种应用程序和系统软件访问。ReFS 吸收了这些优点，并在这一基础上进行了重新构建。我们并非从零开始，而是在适当的 NTFS 组件的基础上进行了适当的重新设计。首先，我们按照一直以来引入主要文件系统的方式以务实的方式引入了此架构，只有 Microsoft 才能以这等规模实施该做法。

代码重用和兼容性

在文件系统 API 这一领域，兼容性是最重要、技术含量最高，同时也最具挑战性的目标。重写文件系统语义的实现代码无法确保适当的兼容性，并且引发的问题将高度依赖于应用程序代码、调用时间和硬件。因此，在构建 ReFS 时，我们重用了用于实现 Windows 文件系统语义的代码。此代码用于实现文件系统接口（读取、写入、打开、关闭、更改通知等），维护内存中的文件和卷状态，执行安全措施，以及维护内存缓存和文件数据同步。这些代码的重用旨在确保与继承自 NTFS 的功能的高度兼容性。

在重用的部分中，我们在 NTFS 版本代码的基础上使用了新架构的引擎，并在其中通过主文件表等磁盘上结构来表示文件和目录。ReFS 将这部分重用代码与一种全新的引擎相结合，这是 ReFS 背后的一大创新。下图展示了这些改进：

NTFS.SYS = NTFS 上层 API/语义引擎 / NTFS 磁盘上存储引擎；ReFS.SYS = 继承自 NTFS 的上层引擎 / 新磁盘上存储引擎

可靠且可扩展的磁盘上结构

磁盘上结构及其操作由磁盘上存储引擎处理。这构成了一种通用的键值接口，其上的层级将利用该接口来实现文件、目录等结构。对于其自身实现，存储引擎将使用专用 B+ 树。事实上，我们以 B+ 树作为唯一的磁盘上结构来表示磁盘中的所有信息。树可以嵌入其他树中（子树的根存储在父树的行中）。在磁盘中，树可以非常大并分为多层，也可以小到只包含几个键并嵌入其他结构中。这确保了该结构具有可全面适应文件系统的可扩展性。使用单一的结构显著简化了系统并减少了代码量。新引擎接口包含“表”的概念，即可枚举的键值对组。大部分表具有唯一的 ID（名为对象 ID），我们可以通过该 ID 来引用特定的表。我们会通过一个特别对象表为系统中的所有此类表建立索引。

现在，我们来介绍一下如何通过表来构建通用文件系统的抽象。

对象表：对象 ID、磁盘偏移量和校验和。指向目录的箭头：文件名、文件元数据；文件元数据：键、值；文件范围：0-07894，磁盘偏移量和校验和；7895-10000，磁盘偏移量和校验和；10001-57742，磁盘偏移量和校验和；57743-9002722，磁盘偏移量和校验和

文件结构

如上图所示，目录以表的形式表示。由于我们使用 B+ 树来实现表，目录可以高效地扩展为极大规模。文件可以作为嵌入父目录行中的表来实现，父目录本身也是一个表（即上图所示的文件元数据）。文件元数据表中的行表示各种文件属性。文件数据的位置范围由嵌入的流表来表示，其中包含偏移值映射（以及可选的校验和）。这意味着文件和目录的规模再大也不会对性能产生影响，突破了 NTFS 的局限。

如您所料，ACL（访问控制列表）等其他文件系统中的全局结构将作为以对象表为根的表来表示。

所有磁盘空间分配都由分层分配器来管理，其中会以空闲空间范围表来表示空闲空间。为了实现可扩展性，我们提供了三种表，大型、中型和小型分配器。这三种表所管理的空间粒度各不相同：例如，中型分配器负责管理由大型分配器分配的中等大小区块。这使得磁盘分配算法非常易于扩展，并且由于相关的元数据会自动并列配置，因此可实现更出色的性能。这些分配器的根和对象表的根都可以通过磁盘上的已知位置访问。某些表具有专用的分配器，以便减少争用并增强区域配置。

除了全局元数据表之外，对象表中的条目引用的目标为目录，因为文件嵌入在目录中。

可靠的磁盘更新策略

可靠而高效地更新磁盘是文件系统设计最重要，也是最具挑战性的领域之一。我们花费了大量时间来评估各种方案。我们曾经考虑过一种日志结构的文件系统，但最终放弃了该方案。这种方案不适合 Windows 所需的通用文件系统类型。NTFS 依靠事务日志来确保磁盘上的一致性。该方案会更新磁盘上现存的元数据，并使用日志作为辅助来持续跟踪更改，以便在发生错误或断电时进行回滚。此方法的优势之一在于维护现存的元数据布局，这有助于提高读取性能。日志系统的主要弊端在于写入可能会变得随机化，更重要的是，如果在写入时断电，更新磁盘的行为可能会损坏之前写入的元数据，该问题通常称为“断写”。

为了尽可能提高可靠性并避免断写，我们选择了一种永不更新现存元数据的写入时分配方案，以原子形式将其写入不同的位置。在某种程度上，这是借鉴了“影式分页”这一古老的概念，该功能用于可靠地更新磁盘上的结构。事务将基于这种写入时分配方案构建。由于 ReFS 的上层派生自 NTFS，新的事务模型将无缝地利用现存故障恢复逻辑，该逻辑已经过数个版本的测试和稳定。

ReFS 的元数据分配方式允许通过更少、更大的 I/O 将相互关联的部件混合写入（例如，流分配、文件属性、文件名和目录页），这对于旋转介质和 flash 都将提供诸多裨益。同时，采取措施保持读取的连续性。分层分配方案在这方面投入了很大的精力。

我们曾经进行过在系统负载极大的情况下断开系统电源的测试，而当系统恢复时，所有结构都会接受正确性检查。本测试是对我们工作成绩的终极衡量。我们在这项 Microsoft 文件系统测试中达到了前所未有的可靠性水平。我们相信该方案已经达到了行业领先水平，并能完全实现我们的关键设计目标。

磁盘损坏还原

如前所述，我们的设计目标之一是检测和更正损坏。这不仅是为了确保数据完整性，也是为了提高系统可用性和联机操作。因此，所有 ReFS 元数据都在 B+ 树页的级别计算了校验和，并将校验和与页本身分别存储。这允许我们检测所有形式的磁盘损坏，包括失写、错写和“位衰减”（介质上的数据降级）。此外，我们还添加了一个选项，供您选择是否计算文件内容的校验和。启用称为“完整性流”的这一选项后，ReFS 始终会将文件更改写入与原始位置不同的位置。这种写入时分配技术可确保不会由于新写入的数据造成之前存在的数据丢失。校验和更新将随数据写入自动进行，因此如果电源在写入时断开，我们始终将具有一个可用于验证一致性的文件版本，并据此权威地检测损坏。

我们曾在数周前发布过一篇有关存储空间的博文。我们在设计 ReFS 和存储空间时旨在令其互为补充，作为一种完整存储系统的两个组件。由于 NTFS 的普及度极高，我们设计的存储空间也适用于 NTFS（及客户端 PC）；在通过结构分层支持此客户端方案的同时，我们还在对 ReFS 进行调整以供用于客户端，最终您将可以同时在客户端和服务器上使用 ReFS。

除了提高性能以外，存储空间还能通过在多个磁盘上维护副本，在发生部分和全面磁盘故障时保护数据。在发生读取故障时，存储空间可以读取备选副本，而在发生写入故障（以及彻底的介质读/写故障）时，该功能可以透明地重新分配数据。许多故障并非由介质故障引发，而是由数据寻坏、失写或错写造成。

这些恰恰是 ReFS 可以通过校验和检测的故障类型。一旦 ReFS 检测到此类故障，将通过存储空间接口读取所有可用的数据副本，并根据校验和验证选择正确的副本。然后，ReFS 将告知存储空间根据正确的副本修复损坏的副本。以上操作完全对应用程序透明。如果 ReFS 未在镜像存储空间上运行，则将无法自动修复损坏。在这种情况下，ReFS 将仅记录一个事件，表明检测到损坏，并且无法判断是否为文件数据。我将在稍后进一步介绍这种情况对元数据的影响。

校验和（64 位）始终对 ReFS 元数据启用，假设该卷寄宿在一个镜像存储空间中，自动更正将始终启用。所有完整性流（见下图）都通过相同的方式获得保护。这将为用户提供一种端到端的高完整性解决方案，将相对不可靠的存储变为高度可靠的存储。

完整性流

完整性流可保护文件免遭任何形式的数据损坏。尽管这种功能在许多情境中颇具价值，但也不适合某些情境。例如，某些应用程序倾向于依靠磁盘上的特定文件布局，细致地管理其文件存储。由于每当文件内容发生变化时，完整性流都会对数据块进行重新分配，因此对于这些应用程序来说，文件布局将非常难以预测。数据库系统是此类应用程序的典型案例。此类应用程序通常也会自行维护文件内容的校验和，并可以通过与存储空间 API 的直接交互来验证和更正数据。

对于此类需要特定文件布局的情况，我们在各粒度级别都提供了用于控制此设置的机制和 API。

在最基本的级别，完整性是文件的一种属性 (FILE_ATTRIBUTE_INTEGRITY_STREAM)。它也是目录的一种属性。当存在于目录中时，它将由目录中创建的所有文件和目录继承。方便起见，您可以在格式化时使用“format”命令来为卷的根目录指定该属性。在根级别设置该属性可确保其默认传播至该卷上的所有文件和目录。例如：

 D:\>format /fs:refs /q /i:enable <volume>

D:\>format /fs:refs /q /i:disable <volume>

默认情况下，如果未指定 /i 开关，则系统选择的行为将取决于该卷是否驻留于镜像空间中。在镜像空间中，完整性将获得启用，因为我们预计这样做所带来的好处将远大于弊端。应用程序随时可以通过编程方式逐个文件地更改此属性。

对抗“位衰减”

如前所述，ReFS 和存储空间的结合将在发生磁盘损坏和存储故障时提供高度的数据弹性。“位衰减”是一种难以检测和处理的数据损坏，它是指部分磁盘随着时间的推移产生损坏，但由于这些部分很少读取而未引起注意。当读取或检测到这些部分时，其备选副本可能已由于其他故障而损坏或丢失。

为了应对位衰减，我们添加了一项系统任务，该任务会定期扫描镜像存储空间中驻留的 ReFS 卷上的所有元数据和完整性流数据。扫描涉及读取所有冗余副本并通过 ReFS 校验和验证其正确性。如果校验和不匹配，损坏的副本将通过正确的副本修复。

FILE_ATTRIBUTE_NO_SCRUB_DATA 文件属性指示扫描器应跳过该文件。此属性适用于自行维护完整性信息的那些应用程序，应用程序开发人员可以密切控制扫描这些文件的时间和方式。

Integrity.exe 命令行工具是管理完整性和扫描策略的一种强大方法。

当所有其他措施都失效时…卷将仍然可用

我们希望大部分用户都能将 ReFS 与镜像存储空间结合使用，这样损坏就可以自动且透明地修复。但在某些极端情况下，镜像空间中的卷也可能发生损坏，例如损坏的系统内存会破坏数据，然后这些数据将进入磁盘并破坏所有备份副本。此外，某些用户可能不会选择在 ReFS 下使用镜像存储空间。

对于这些卷发生损坏的情况，ReFS 将实施“数据打捞”，该功能可将损坏的数据从活动卷的命名空间中移除。此功能旨在确保无法修复的损坏不会影响正确数据的可用性。例如，目录中的单个文件已损坏且无法自动修复，ReFS 会将该文件从文件系统命名空间中移除，同时对该卷的余下部分进行打捞。此操作通常可在一秒内完成。

通常，文件系统无法打开或删除损坏的文件，管理员也对此束手无策。但由于 ReFS 能够打捞损坏的数据，管理员将能够通过备份来恢复该文件或通过应用程序来重新创建该文件，同时保持文件系统的联机状态。这一关键创新可确保我们无需运行昂贵的脱机磁盘检查和更正工具，并避免了数据量极大的卷由于损坏而产生较长的脱机期所带来的风险。

完美兼容 Windows 存储堆栈

我们意识到自己的设计必须具备最大的灵活性和兼容性。我们设计的 ReFS 与其他文件系统一样可以插入存储堆栈，以便尽可能提高对其周边层级的兼容性。例如，ReFS 可以无缝利用 BitLocker 加密、用于安全的访问控制列表、USN 日志、更改通知、符号链接、交接点、装入点、重解析点、卷快照、文件 ID 和操作锁。我们预计大部分文件系统过滤器无需或只需小幅调整即可无缝地用于 ReFS。我们的测试证明了这一点；例如，我们已验证了现有的前沿反病毒解决方案可以正常工作。

某些依赖 NTFS 物理格式的过滤器需要进行更大的调整。我们会通过大规模的兼容性程序测试我们的文件系统与第三方反病毒、备份和其他此类软件的兼容性。对于 ReFS 我们也采取了相同的做法，并将与我们的主要合作伙伴密切协作来解决我们发现的任何不兼容问题。这些措施不仅限于 ReFS，我们在以前也多次这样做。

还有一项值得注意的灵活性，尽管 ReFS 和存储空间适合结合使用，但它们实际上是可以分别独立运行的两个组件。这可以同时为两种组件提供最大的部署灵活性，避免不必要的相互限制。换句话说，您可以在选择存储解决方案时在可靠性和性能方面进行权衡，包括将 ReFS 与来自我们合作伙伴的底层存储解决方案联合部署。

借助存储空间，存储池可以由多台计算机共享，并且虚拟磁盘可以在这些计算机之间实现无缝迁移，提供额外的故障弹性。由于我们构建该系统的方式，ReFS 可以无缝地利用这些优势。

使用

20 多年来，我们针对 NTFS 开发了数万种复杂而庞大的测试，并使用它们对 ReFS 进行了测试。在系统压力测试、断电等故障测试、可扩展性测试和性能测试等方面，ReFS 都满足并超出了我们预计的部署要求。因此，ReFS 已经准备好在受控的环境中接受部署测试。作为主要文件系统的最初版本，我们建议谨慎地进行该测试。我们并未将 ReFS 作为 Windows 8 中的“测试”功能发布。当 Windows 8 结束测试后，ReFS 将作为生产就绪功能发布，并会告诫您数据的可靠性才是至关重要的。因此，与系统的任何其他方面不同，您需要通过谨慎的做法对其进行最初的部署和测试。

在这一前提下，我们会将 ReFS 作为一种阶段性演进功能进行部署：首先作为 Windows Server 的存储系统，然后作为客户端的存储系统，最终作为启动卷。之前我们也曾针对新文件系统采取过相同的做法。

最初，我们的主要测试将聚焦于作为文件服务器运行的 ReFS。我们希望用户能够通过将其作为文件服务器而获益，尤其是在镜像存储空间中。我们还计划与我们的存储合作伙伴密切协作，以便与他们的存储解决方案相集成。

结论

ReFS 和存储空间共同构成了 Windows 在今后十年或更长时间内使用的存储基础。我们相信这将显著强化我们在存储领域的领先地位。存储空间和 ReFS 的架构中还预留了进一步创新的空间，我们期待 ReFS 能够成为下一种大规模部署的文件系统。

-- Surendra

常见问题解答：

问：为什么将其命名为 ReFS？

ReFS 是弹性文件系统 (Resilient File System) 的缩写。尽管该系统在很多方面都进行了优化，但弹性是其中最突出的一种功能。

问：ReFS 的容量限制是多少？

下表显示了磁盘上格式的容量限制。其他因素可能会决定某些实践限制，例如系统配置（例如内存大小）、各种系统组件设置的限制、填充数据集所需的时间以及备份次数等。

属性

磁盘上格式的限制

单个文件的最大规模

2^64-1 字节

单个卷的最大规模

格式支持带有 16KB 群集规模的 2^78 字节 (2^64 * 16 * 2^10)。Windows 堆栈寻址允许 2^64 字节

目录中的最大文件数量

2^64

卷中的最大目录数量

2^64

最大文件名长度

32K Unicode 字符

最大路径长度

32K

任何存储池的最大规模

4 PB

系统中存储池的最大数量

无限制

存储池中空间的最大数量

无限制

问：我能否在 NTFS 和 ReFS 之间转换数据？

Windows 8 中无法转换现有数据。数据可以复制。考虑到当前所面对的数据集规模，预先进行此转换的困难性，以及在转换前后架构的可能变化，我们有意地做出了此决定。

问：我能否在 Windows Server 8 中从 ReFS 启动？

不能，目前尚未实现也不支持该功能。

问：ReFS 是否可用于可移除介质或驱动器？

不能，目前尚未实现也不支持该功能。

问：ReFS 不再支持哪些 NTFS 的语义或功能？

我们在 ReFS 选择不再支持的 NTFS 功能包括：命名流、对象 ID、短名称、压缩、稳健级加密 (EFS)、用户数据事务、稀疏、硬链接、扩展属性和配额。

问：奇偶校验空间能否与 ReFS 结合使用？

ReFS 支持存储空间提供的错误还原选项。在 Windows Server 8 中，自动数据更正仅针对镜像空间实施。

问：是否支持群集？

支持故障转移群集，各卷可以跨计算机实现故障转移。此外，支持群集中的共享存储池。

问：RAID 呢？我如何使用 ReFS 的条带化、镜像或其他形式的 RAID 功能？例如，ReFS 是否可以提供视频所需的读取性能？

ReFS 可利用存储空间的数据备份功能，包括条带化的镜像和奇偶校验。ReFS 的预计读取性能与 NTFS 相似，因为二者之间共享了大量相关代码。它将非常适合流数据。

问：为什么 ReFS 中没有重复数据删除、DRAM 和存储间的二级缓存以及可写入快照？

ReFS 本身不提供重复数据删除。这种熟悉、可插入的文件系统架构的一个副作用是其他重复数据删除产品可以按照与 NTFS 相同的方式插入 ReFS。

ReFS 并未专门实施二级缓存，但用户可以使用第三方解决方案来实现此功能。

可将 ReFS 和 VSS 结合使用，以便按照与 Windows 环境中的 NTFS 一致的方式提供快照。目前，它们尚不支持可写入快照或超过 64TB 的快照。

Comments

  • Anonymous
    May 11, 2012
    "最大文件名长度 32K Unicode 字符"使用UNICODE后，不会再乱码了吧!???
  • Anonymous
    November 15, 2012
    @NONE  WIN7系统中有对于UNICODE支持的问题么
  • Anonymous
    August 06, 2013
    为何在ReFS卷上没法使用Windows Server 2012的NFS共享？