当前位置:网站首页 > Windows运维 > 正文

ReFS

作者:jinxijing发布时间:2019-03-05分类:Windows运维浏览:240


导读:ReFSReFS(ResilientFileSystem,弹性文件系统)是在WindowsServer2012中新引入的一个文件系统。目前只能应用于存储数据,还不...

ReFS

ReFSResilient File System,弹性文件系统) 是在Windows Server 2012中新引入的一个文件系统。目前只能应用于存储数据,还不能引导系统,并且在移动媒介上也无法使用。

ReFS是与NTFS大部分兼容的,其主要目的 是为了保持较高的稳定性,可以自动验证数据是否损坏,并尽力恢复数据。如果和引入的Storage Spaces(存储空间)联合使用的话则可以提供更佳的数据防护。同时对于上亿级别的文件处理也有性能提升。

中文名

弹性文件系统

外文名

Resilient File System

    

ReFS

应用系统

Windows Server 2012

格式化为ReFS

编辑

ReFS最初只应用于Windows Server 2012服务器版本中,对于Windows 8桌面版本则没

有得到正式应用。

直到在Windows 10 v1703ReFS首次亮相于桌面版本并默认开启了格式化功能,而在Windows 10 v1709中微软将其变更为仅在专业工作站版和企业版中才开放格式化并默认收回了其他SKU版本创建ReFS卷功能(对于已格式化现有的ReFS卷在这些SKU中仍然可用)。

历史版本和兼容性

编辑

ReFS存在一些不同的版本,它与操作系统版本之间具有不同程度的兼容

性。除了该文件系统的内测开发版本外,通常较新版本的操作系统可以装载使用较早版本的操作系统(向下兼容)所创建的ReFS卷,反之则不能兼容。可以在CMD命令提示符使用"fsutil fsinfo refsinfo x:"(不含引号)命令查询该文件系统当前的版本号,其中"X"改为需要查询ReFS卷的盘符。注意此命令受支持的最低操作系统版本为Windows Server 2016Windows 10

ReFS已发行的版本号:

v1.1:初始版本,由Windows Server 2012格式化创建的默认版本。


  v1.2:由Windows Server 2012 R2格式化创建的默认版本。在Windows Server 2016Windows 10 v1703及更高版本系统的命令行中指定ReFSv1格式化创建的默认版本。
  v2.0:由Windows Server 2016 TP2TP3格式化创建的默认版本。在Windows Server 2016 Technical Preview 4及更高版本中无法装载使用。
  v3.0:由Windows Server 2016 TP4TP5格式化创建的默认版本。
  v3.1:由Windows Server 2016 RTM格式化创建的默认版本。
  v3.2:由Windows 10 v1703Windows Server IP v1709 Build16237格式化创建的默认版本。
  v3.3:由Windows 10 v1709Windows Server IP v1709 Build16257格式化创建的默认版本。Windows 10 v1709Insider Preview Build16226开始仅支持在专业工作站版和企业版中创建ReFS卷。
  v3.4:由Windows 10 v1803v1809Windows Server 2019格式化创建的默认版本。Windows ServerInsider Preview v1803 Build17083开始ReFS升级为3.4版本。

注释:
  1、当ReFSv3.X的较低版本在较高版本的系统中以可读写状态装载时,Windows默认会自动将其升级为较高的版本(对于ReFSv1.X则不会自动升级)。
  2、升级过后的ReFS卷在之前的较低版本Windows中将无法被识别,且除了在较低版本系统中重新格式化外没有其他办法能够降级。
  3、如需禁止Windows自动升级ReFS版本号则需要修改以下注册表键值:
  按下Windows徽标+R快捷键打开运行窗口,输入 regedit.exe 确定打开注册表编辑器并在其左侧点击定位到以下路径
  HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\FileSystem
  点击 FileSystem 项后在右侧空白处右键新建一个DWORD(32)键值并将其重命名为"RefsDisableVolumeUpgrade"(不含引号,如已存在则不需要再新建),双击打开并将其数值数据设置为 1 确定后重启系统生效。

文件系统目标

编辑

保持对一部分广泛采用的 NTFS 功能的兼容性,同时放弃其他价值有限但会大幅增加系统复杂性和占用率的功能。

验证并自动更正数据。数据可能会由于各种原因而损坏,因此必须对其进行验证,并在可能的情况下进行自动更正。元数据必须写入适当的位置,以避免出现"断写",我们将在下文中详细介绍该情况。

针对超大规模应用进行优化。使用普遍适用的可扩展结构。不要假设磁盘检查算法可以扩展到整个文件系统的规模。

确保文件系统永不脱机。当出现损坏时,最佳的解决方案是隔离错误,并允许继续访问余下的卷,同时尽可能打捞所有可用的数据,并且这一切都通过实时的方式完成。

借助与 ReFS 联合设计和构建的存储空间功能,提供完整的端到端弹性结构。

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

带有校验和的元数据完整性

提供可选用户数据完整性的完整性流。

通过写入时分配事务模型实现可靠的磁盘更新(也称为写入时复制)

支持超大规模的卷、文件和目录

存储池和虚拟化使得文件系统可建立并易于管理

通过数据条带化提高性能(带宽可管理)并通过备份提高容错性

通过磁盘扫描防止潜在的磁盘错误

借助"数据打捞"实现损坏还原,以便在任何情况下尽可能提高卷的可用性

跨计算机共享存储池,以提供额外的容错性和负载平衡

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

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

关键设计属性和功能

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

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

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

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

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

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

如上图所示,目录以表的形式表示。由于我们使用 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 能够打捞损坏的数据,管理员将能够通过备份来恢复该文件或通过应用程序来重新创建该文件,同时保持文件系统的联机状态。这一关键创新可确保我们无需运行昂贵的脱机磁盘检查和更正工具,并避免了数据量极大的卷由于损坏而产生较长的脱机期所带来的风险。

完美兼容存储堆栈

我们意识到自己的设计必须具备最大的灵活性和兼容性。我们设计的 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 能够成为下一种大规模部署的文件系统。

常见问题

编辑

问:为什么将其命名为 ReFS

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

问:ReFS 的容量限制是多少?

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

问:我能否在 NTFS ReFS 之间转换数据?

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

问:我能否在 Windows Server 2012 中从 ReFS 启动?

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

问:ReFS 是否可用于可移除介质或驱动器?

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

问:ReFS 不再支持哪些 NTFS 的语义或功能?

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

问:奇偶校验空间能否与 ReFS 结合使用?

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

问:是否支持群集?

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

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

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

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

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

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

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

属性

磁盘上格式的限制

单个文件的最大规模

2^64-1 字节

单个卷的最大规模

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

目录中的最大文件数量

2^64

卷中的最大目录数量

2^64

最大文件名长度

32K Unicode 字符

最大路径长度

32K

任何存储池的最大规模

4 PB

系统中存储池的最大数量

无限制

存储池中空间的最大数量

无限制