CN1694098B - 实时文件系统修复 - Google Patents

Abstract

一种文件系统能够进行对盘上数据的检测到的损坏的实时校正。对文件系统的增强实时响应在运行卷上检测到的文件系统损坏，并在文件系统检测到它们的那一点修复该损坏。在由文件系统检测损坏之后，系统增强记录描述该损坏的特性的信息。对遇到的每种类型的损坏确定一修复扫描。修复扫描能在检测到损坏的当前线程的执行的顶层上运行，或它们需要专门的线程来服务该修复操作。

Description

实时文件系统修复

相关申请

本申请要求对NO.60/566,662，2004年4月30日提交的美国临时专利申请的优先权。

技术领域

本发明一般涉及文件系统，尤其涉及支持在运行的卷上检测到损坏的实时校正的文件系统。

背景技术

在计算机中的文件系统规定在计算机的存储卷(如硬盘)上存储数据文件，以及如何从该卷检索文件的方法。例如，Windows、OS/2、Macintosh、和基于UNIX的操作系统具有文件系统，它们使用分层或树型结构来维护文件。文件系统还规定命名文件的约定，如在文件名字中能使用多少字符，哪些字符可用于文件名，和在文件名的后缀中允许多少字符。

术语“文件系统”常用于指文件系统驱动程序、程序、或管理文件系统结构、约定、和有关任务的操作系统的部分。因此，文件系统响应于不同的用户/应用程序的请求执行诸如打开、读、写、重命名、和关闭文件等操作。管理文件系统事务的重要一方面是维持文件系统中的内部完整性。一般而言，文件系统希望硬盘(即存储卷)上的数据结构一致，并保持通用文件系统格式。例如，当数据以特定格式写到该盘上时，文件系统期望能够以同样格式从该盘读回该数据。然而，存在引起在盘上的数据损坏的各种情况。例如盘(即，具体的存储介质)的问题可导致丢失数据比特。在计算机和硬盘之间存在连接问题，这导致数据不能正确地写入盘或正确地从盘中读出。在操作系统或驱动程序中可能存在编程错误，导致数据写入存储器中随机位置。因此，数据事务的各种问题和其它问题能引起文件系统的数据结构的损坏。

文件系统通常采用一进程来校验并修补由于不正确或不完全的事务引起的损坏。例如，由来自华盛顿州雷特蒙德的微软公司的各种操作系统使用的NTFS(新技术文件系统)采用了一种Autochk/Chkdsk实用程序，它扫描文件卷以确保数据结构是一致的并不存在损坏。Autochk/Chkdsk实用程序在每次安装在系统上时在NTFS卷上运行，而安装是最通常发生在系统起动或重起动时。当NTFS在运行卷上发现一损坏问题，它将该卷标记为“dirty(脏)”，并向用户呈现损坏错误。然后，在重起动系统之后，若NTFS遇到“脏”卷或其它不一致性，自动执行Autochk/Chkdsk，且安装该卷的引导请求被延迟或被拒绝。例如，Chkdsk实用程序也能由希望控制该实用程序运行次数的较大计算机系统的系统管理员人工启动。在Chkdsk针对卷运行时(即扫描该卷进行修复)，用户不能访问该卷。根据找到的损坏类型，Chkdsk可采取特定的校正行动来修复该损坏。例如，若在盘上存在表明文件被分配在哪里的不一致或损坏的信息，Chkdsk将删除该文件。若存在不可读或损坏的文件目录，Chkdsk将重建该目录。

虽然那些文件恢复实用程序(如Chkdsk)通常在修复文件系统损坏方面是成功的，但它们具有缺点。如上所述，一个缺点是它们对用户来说能是破坏性的。Chkdsk能占用长时间来运行，且需要独占地访问它所扫描和修补的卷(如硬盘)。因此，在起动计算机之后，用户可能不能访问该卷，而相反在起动过程完成之前必须等待，直到Autochk/Chkdsk结束其修复工作。在如服务一企业系统的大型服务器上，运行Autochk/Chkdsk占用的时间能是很长的。大型服务器能具有数以百万计的文件，它占用许多小时(如10-15小时)以由Autochk/Chkdsk处理。因此，若管理员不注意在一天的什么时候执行Autochk/Chkdsk实用程序，许多用户会是不方便的。

因而，对于修复卷上的文件系统损坏而不破坏卷或阻止对卷的访问的方法存在需求。

发明内容

一种启用了文件系统损坏的实时校正的系统和方法。对文件系统的增强实时地响应在运行卷中检测到的文件系统的损坏，并在文件系统检测到损坏的地方修复它们，而不必锁定整个卷，使得在该卷上的其它操作能继续。在由文件系统检测损坏之后，该系统增强记录描述损坏的性质的信息。对遇到的损坏的每种类型确定修复扫描。根据修复的复杂性，修复能对检测损坏的用户请求同步或异步地发生。在后一种情况，通知应用程序通知关于正进行的修复。

附图说明

在诸图中使用相同的参考标号以参照类似的组件和特征。

图1示出适用于实现提供运行卷上检测到的损坏的实时和在线修复的增强的文件系统的示例计算环境。

图2示出配置成实现提供运行卷上检测到的损坏的实时和在线修复的增强的文件系统的计算机的示例性实施例。

图3-5是示出用于实现提供运行卷上检测到的损坏的实时和在线修复的增强的文件系统的示例性方法的流程图。

具体实施方式

引言

下面讨论针对增强的文件系统及方法，它们提供运行卷上检测到的损坏的实时和在线修复。该文件系统是自校正的，它检测损坏，确定用于校正损坏的合适的修复并实现修复，同时以基本上不中断的方式继续管理文件系统操作。在修复操作期间，卷保持在线及有效。

增强的文件系统的优点包括对计算机用户减少破坏性，因为损坏在它们产生时被修复，而不是由在起动时间或在管理员设定的特定时间运行的修复实用程序一次性修复。

示例性计算环境

图1示出适用于实现提供运行卷上的检测到的损坏的实时和在线修复的增强的文件系统的示例性计算环境。虽然在图1中示出一具体配置，那样的计算设备能在其它计算机配置中实现。

计算环境100包括以计算机102形式的通用计算系统。计算机102的组件包括但不限于：一个或多个处理器或处理单元104、系统存储器106、和将包括处理器104的各种系统组件耦合到系统存储器106的系统总线108。

系统总线108代表若干类型总线结构的任一种的一个和多个，包括存储器总线或存储控制器、外围总线、加速图形端口、和使用各种总线体系结构的任一种的处理器或局部总线。系统总线108的例子是也称为Mezzanine总线的外围部件互连(PCI)总线。

计算机102包括各种计算机可读介质。那样的介质能是可由计算机102访问的任何可得到的介质，并包括易失和非易失、可移动和不可移动介质。系统存储器106包括以如随机存储器(RAM)110的易失存储器形式和/或如只读存储器(ROM)112的非易失存储器形式的计算机可读介质。基本输入/输出系(BIOS)114包含如在起动时帮助在计算机102中的各元件之间传输信息的基本例程，被存储在ROM 112中。RAM 110包括由处理单元104立即访问和/或即时操作的数据和/或程序模块。

计算机102也包括其它可移动/不可移动、易失/非易失计算机存储介质。例如，图1示出用于读写不可移动、非易失磁介质(未示出)的硬盘驱动器116、用于读写可移动、非易失磁盘120的(如“软盘”)磁盘存储器118、和用于读写如CD-ROM、DVD-ROM、或其它光介质的可移动、非易失光盘124的光盘驱动器122。硬盘驱动器116、磁盘驱动器118、和光盘驱动器122均通过一个或多个数据介质接口125连接到系统总线108。另外，硬盘驱动器116、磁盘驱动器118、和光盘驱动器122可通过SCSI接口(未示出)连接到系统总线108。

盘驱动器及其相关的计算机可读介质为计算机102提供计算机可读指令、数据结构、程序模块、及其他数据的非易失存储。虽然例子示出了硬盘116、可移动磁盘120、和可移动光盘124，可以理解，能存储计算机访问的数据的其它类型计算机可读介质也能用于实现示例的计算系统及环境，如：磁带盒或其它磁存储设备、闪存卡、CD-ROM、数字多功能盘(DVD)或其他光存储器、随机存储器(RAM)、只读存储器(ROM)、电可擦除只读存储器(EEPROM)等。

任何数目的程序模块能存储在硬盘116、磁盘120、光盘124、ROM 112、和/或RAM 110中，例如包括操作系统126、一个或多个应用程序128、其它程序模块130、和程序数据132。那样操作系统126、一个或多个应用程序128、其它程序130、和程序数据132(或它们的某种组合)的每一个能包括用于用户网络访问信息的高速缓冲方案的实施。

计算机102能包括被标识为通信介质的各种计算机/处理器可读介质。通信介质在诸如载波或其它传输机制等已调制数据信号中包含计算机可读指令、数据结构、程序模块、或其它数据，并包括任何信息传送介质。术语“已调制数据信号”指的是以如在信号中编码信息的方式设置或改变其一个或多个特征的信号。例如但不限于，通信介质包括有线介质，如有线网络或直接连接，和无线介质，如声音、RF、红外或其它无线介质。上述的任何组合能包括在计算机可读介质的范围中。

用户能通过如键盘134和定位设备136(如“鼠标”)的输入设备输入命令和信息到计算机系统102。其它输入设备138(未专门示出)能包括麦克风、操作杆、游戏垫、圆盘式卫星天线、串行端口、扫描仪和/或其类似物。这些和其它输入设备通过耦合到系统总线108的输入/输出接口140连接到处理单元104，但也可通过其它接口和总线结构连接，如并行端口、游戏端口或通用串行总线(USB)。

监视器142或其它类型的显示设备也能通过如视频适配器144的接口连接到系统总线108。除了监视器142以外，其它输出外围设备能包括如扬声器(未示出)和打印机146等组件，它们能通过输入/输出接口140连接到计算机102。

计算机102能使用到如远程计算设备148的一个或多个远程计算机的逻辑连接在网络环境中操作。例如，远程计算机148能是个人计算机、便携计算机、服务器、路由器、网络计算机、对等设备或其它公共网络节点等。远程计算机148被示作便携机，它能包括这里相对于计算机系统102描述的许多或所有元件和特征。

在计算机102和远程计算机148之间的逻辑连接被画成局域网(LAN)150和普通广域网(WAN)152。那样的网络环境在办公室、企业范围计算机网络、内联网、和因特网中是常见的。在LAN网络环境中实现时，计算机102通过网络接口或适配器154连接到局域网150。在WAN环境中实现时，计算机102包括调制解调器156或用于通过广域网152建立通信的其它装置。对计算机102是内置或外接的调制解调器156通过输入/输出接口140或其它合适机制连接到系统总线108。可以理解，示出的网络连接是示例性的，能采用在计算机102和148之间建立通信链路的其它装置。

在如用计算环境100示出的网络环境中，相对于计算机102画出的程序模块或其部分可存储在远程存储器设备中。例如，远程应用程序158驻留在远程计算机148的存储器设备中。为说明起见，应用程序和其它可执行程序组件，如操作系统在这里示作分别的块，虽然可以看到，那些程序和组件在不同时间驻留在计算机系统102的不同存储器组件上，且由计算机的数据处理器执行。

示例性实施例

图2示出被配置成实现增强的文件系统的计算机102的示例实施例，它提供运行卷上检测到的损坏的实时和在线的修复。计算机102包括被配置成执行存储在存储器206中的操作系统202和各种应用程序204的一个或多个处理器200。在整个专利说明中使用的术语“卷”一般指的是数据存储的可标识单元。因此，一个卷能是在如硬盘210的具体存储单元上若干单独可标识的诸卷之一。

文件系统驱动程序208(后面称为文件系统208)也存储在计算机102的存储器206中。通常，文件系统或文件管理系统是用于在计算机102的卷210(如硬盘)上存储文件的结构或约定，如其中目录在其下面具有文件及子目录的分层系统。因此，文件管理系统规定数据文件在计算机的硬盘上存储的方法、文件如何从卷检索、命名文件的约定等。术语“文件系统”常用于指文件系统驱动程序、程序、或支持或管理文件管理系统的操作系统的部分。文件系统驱动程序解释盘上格式以管理文件系统的结构和约定，并响应于各种用户/应用程序的请求完成如打开、读、写、重命名、和关闭文件等文件操作。在此情况下，在此整个说明中讨论存储器206中存储的文件系统驱动程序/代码208。即，文件系统208指的是如上讨论支持和管理更一般的文件管理系统的程序或操作系统的部分(即，可执行码)。

因而，文件系统208被配置成在计算机102的硬盘210的一个或多个卷上完成与文件管理关联的各种操作。例如，文件系统208响应于不同的用户/应用程序的请求完成如打开、读、写、重命名和关闭文件等文件事务。如图2所示，文件系统208通常与操作系统202集成。然而，文件系统208不限于为操作系统202的集成部分，也可以是独立的应用程序或程序模块。此外，虽然存储器206在图2中被示出为与硬盘210分开，应注意，存储器206能部分地或全部地是硬盘210的一部分。硬盘210和存储器206在图2中分别示出仅是为了讨论的目的。因此，虽然操作系统202和各种应用程序204被示作存储在存储器206中，它们可以存储在硬盘210的一个或多个卷上。

在本实施例中，文件系统208作为由华盛顿州雷蒙德的微软公司的各种操作系统使用的NTFS(新技术文件系统)文件系统来讨论。然而，作为示例性文件系统使用NTFS不试图限制所讨论的文件系统增强可以应用的其它文件系统和操作系统。因此，用于这里描述的实时文件系统修复的文件系统增强可应用到在如OS/2、Macintosh、和基于UNIX操作系统的各种操作系统中使用的不同的文件系统。

如上所述，管理文件系统事务的一个重要方面是保持文件管理系统中内部的完整性。在盘210的卷上的数据损坏可以由各种问题引起，如盘210上的物理变异、在计算机102和硬盘210之间的连接问题、或操作系统或驱动程序中导致数据被写入存储器上随机位置的编程错误。

实时修复模块212被配置成文件系统208的一部分，来帮助维护计算机102的文件系统的完整性。实时修复模块212通常被配置成提供由文件系统208检测的损坏的实时和在线修复。本节的余下部分描述响应于在运行系统中的卷上检测到的损坏，结合文件系统208的实时修复模块212的操作，并概述检测、调度、报告和管理修复处理的基本过程。这些内容的每一个的附加细节在题为附录的后面章节上讨论。

实时修复模块212被配置成在文件系统208出现损坏状态指示符/错误的当前代码点上作出响应。那时，文件系统208记录所需要的所有信息以启动对特定错误的修复过程。修复扫描能回到当前线程的执行的顶层执行。然而更复杂的修复扫描需要专用的线程。

许多修复与当前操纵运行系统中的文件的所有用户相兼容，并因而能完全透明地修复。在修复与操纵运行系统中的文件的用户不兼容时，用户能看到关于修复的附带效应。例如，实时修复模块212能将一个流截断到零长度，而仍然存在访问此同一流的有效句柄(handle)。那样的文件系统修复和与写程序共享的句柄兼容，但在其它情况不兼容。不兼容的句柄必须作废，且在不兼容的句柄上的进一步操作将失败。

对于由于某种形式的损坏而不能完成的对文件系统208的顶层请求可能以一错误状态失败，或可以被阻断，直到完成短期的修复。关于当前的文件系统请求检测到的损坏可以是在当前请求本身中最初检测到的，或能作为关于以前的请求的早期检测的结果已被检测到，并正在被修复的过程中。在任一情况下，确定修复复杂性的等级，它表明应采取的合适的校正行动。

文件系统208和修复模块212对响应于损坏检测而调度的修复操作给予优先级。由于减少了在各组件间的依赖性，这简化了设计未来特征。

在检测损坏时，文件系统208在从硬盘210中读出并处理元数据时验证元数据。文件系统208直接检测元数据损坏，并产生表示每一损坏的错误状态。在检测到损坏的点，文件系统208和修复模块212确定所需修复的范围，并在当前线程的顶层文件系统上下文结构中记下。通常，文件系统208已经在带有损坏的元数据流上保持锁定，并能在相关的数据结构上设置必要的状态信息，以表明它们在无效状态或正在修复。这就允许修复模块212将修复操作与这些同样的文件上的未完成的和未来的请求同步。

文件系统208和修复模块212还处理由于其它组件中的故障而引起的损坏。这一损坏的两个主要原因是在日志文件中的数据丢失和失败的文件系统事务中止。日志文件故障通常发生在卷重起时间。引起损坏状态，且文件系统208不能安装该卷(如盘210)。修复模块212捕捉此错误并促使日志文件的重新初始化，文件系统208可以选择在此点忽略可能的卷损坏，并依赖运行系统中检测损坏的正常机制。

实时修复模块212通过处理检测到的损坏的列表的单个例程完成修复，并具有等待完成修复的文件系统用户请求的列表。复杂的修复扫描可能需要专门的线程来服务修复操作。专门的线程只在需要时产生，且它将调用相同的公共修复例程。小规模的修复例程在堆栈中执行的顶层点内嵌地运行。它们通常处理长度为1的修复队列，并挂起长度为1的IRP队列。这允许多个修复并行地发生。在这些本地修复操作之一击中(hit)层叠的或更复杂的损坏时，本地工作队列和IRP队列能迁移到全局工作队列。这也促使其它本地修复操作中止并转移到全局工作队列。

能在递归的文件系统请求中检测损坏。在此情况下，文件系统208展开到顶层请求以完成修复。这就保证修复的执行期间，没有资源被文件系统208中的调用程序所占用。若文件系统208不能返回到不占用资源的顶层，则它将修复记入工作队列，并停止当前线程中的请求。在任何情况下，所有递归的文件系统请求需要以损坏状态错误失败。这能影响文件系统过滤器，它在不同请求的情况中启动请求。

在某些情况下，由于损坏的引导扇区或MFT(主文件表)文件中的断开连接，文件系统208不能安装卷(如盘210)。在存在损坏的引导扇区的情况下，不肯定哪个文件系统实际上“拥有”该卷。因此，文件系统208不能采取单方面的行动来扫描磁盘210以重建元数据并修复引导扇区。这是因为可能在卷上存在常驻的文件系统元数据，但是该卷可能已被快速地格式化成不同的文件系统。在这些情况下，需要由管理员运行离线的工具，它能强制该卷被处理成如NTFS卷那样的特定文件系统卷。那样的离线工具能扫描该卷，重建引导扇区。一旦引导扇区就绪，则文件系统208能做它自己的卷扫描，以重建其余文件系统元数据。此完全扫描将完成损坏引导扇区文件的修复过程，且它能处理MFT文件中断开连接的问题。

文件系统208(结合实时修复模块212)记录描述在检测损坏时遇到的损坏的性质的关键信息。文件系统208和修复模块212确定一系列对应于所检测到损坏的类型的修复扫描。生成一工作项，它对应于在损坏检测时刻确定的修复扫描。某些复杂的修复扫描是较低层扫描加上附加校验的集合。完成作为较低层扫描的集合的复杂修复保证较低层扫描的正确性(做文件校验保证属性正确)。其它修复扫描是分层的，因为当前运行的扫描能取决于在它成功地运行之前其它文件系统元数据的正确性(如，目录的重建能阻碍该目录中包括的文件的文件名校验)。

文件系统208维持在损坏检测期间产生的工作项和当前进行的修复及正挂起的修复之间的关系。包含在更复杂的扫描中的修复扫描将被折叠成更复杂的扫描。当复杂的扫描完成时，则每个组件扫描也被认为已完成。分层的修复扫描在它们所依赖的扫描完成时被触发。为了维持这些关系，文件系统208支持中止一个正进行的修复扫描，以完成以上更高优先级的扫描。

修复扫描的某些例子包括：

·属性扫描

·文件扫描

·索引扫描

·卷位图重建

·安全性描述符文件扫描。

带有实时修复模块212的文件系统208也处理在执行修复扫描时遇到另外的损坏的情况。为了保持干净的体系结构模型，当前修复扫描和遇到的损坏的类型之间的关系适应两类上述相关的修复扫描之一。当前修复扫描或者被折叠成包含元数据对象的修复(即，在修复属性时检测到的另外的文件损坏)，或者被推迟直到新的修复扫描完成(即，目录验证被推迟直到目录中文件的文件记录被修复)。这需要小心地确定各个工作项，使得在做修复时任何可能遇到的损坏能被调度和修补，而对原始的修复没有任何依赖性。

带实时修复模块212的文件系统208以对运行系统中的应用程序的最小影响的方式执行修复，并提供关于在修复期间作出的改变的性质的完全报表。然而，由于文件系统损坏的修复，客户机应用程序204可能受影响，这取决于修复的严重程度和打开句柄的方式。若修复是快的，则由该应用程序生成的任何顶层IRP在修复进行的同时作出等待。在这一情况下，修复操作对应用程序204应是透明的。然而若修复是非一般的，则对文件系统208的应程序用请求可能以损坏状态错误失败。

应用程序204需要管理修复操作的结果，包括对包括应用程序204的可执行代码和正使用的数据文件的修复。若可能，文件系统208通过USN和通知事件报告改变。若那些改变与当前的访问和文件的共享方式兼容，则该应用程序204能够无意外地进行。然而，若该修复不与应用程序204兼容，则应用程序204将接收无效句柄状态错误。应用程序204需要管理它们的句柄不再能用于访问该文件的情况。一般而言，采用文件系统208和修复模块212，可令文件可访问而不必卸载和修复。

文件系统208不试图在盘上记录当前正被修复或排队等待修复的每个损坏。因为文件系统208在运行系统中会再次遇到和修复损坏，开发必须保证保存所有损坏的复杂的盘上表示得益甚少。然而，通知长的运行扫描在进行和在运行系统中最后到达的点是很有用的。文件系统208能将此信息放在盘210的卷文件记录中。然而，不可能保证此信息在盘上是正确的，因为它本身也受到损坏。文件系统208也可能在修复运行系统中卷文件记录的过程中，所以此时可能不能写到此记录。

文件系统208使用状态文件损坏错误码及状态盘损坏错误码，以表明由于某些损坏有关错误造成当前操作何时失败。存在三类以这些状态码失败的故障：

·在执行操作时遇到的损坏一需要非一般的修复；

·用户操作需要长期运行修复完成；

·由于修复工作句柄现在无效-文件系统以与共享方式、希望的访问、文件上保持的文件锁或操作锁(oplock)不兼容的某种方式修复文件。

文件系统208还提供功能以允许授权的用户与修复过程交互。系统管理员能够在文件系统元数据上启动验证扫描。文件系统208提供灵活性，使得管理员能规定验证的范围，这能包括下列：

·全卷扫描

·安全性扫描

·文件扫描

·流扫描

·目录扫描

·视图索引扫描

文件系统208还提供报告当前复杂修复操作及进行状态的机制。不必要报告任何关于不重要修复操作的信息，因为用户应当从不看到由于这种损坏的存在的文件系统请求失败。然而应注意，不重要的修复能使打开的句柄无效。

文件系统208还提供能在修复操作之后阻断的通知机制。系统管理员能使用卷句柄来等待任何复杂的修复或验证扫描的进行。为了做此工作，文件系统208不会由于损坏而停止卷的打开。在得到该句柄上的状态损坏错误的用户能使用该句柄来等待该句柄上修复的完成。

若修复在进行，则卷卸载不被重要地阻断。任何短期修复能完成。需要由用户重新启动长运行时间的修复扫描。对于修复队列中其它不重要的错误的修复将被取消，且当在下一次卷安装时发现这些错误时重新尝试。

带实时修复模块212的文件系统208可以是ID、CPU或存储器密集型的，因为它扫描通过执行修复操作的卷。在某些资源缺少的环境，此开销是不可接受的。在那种情况下，文件系统208提供一种方法，禁止对长期运行扫描的自动修复，并需要管理员直接启动该扫描。单方面的短期的修复操作仍由文件系统208启动。

带实时修复模块212的文件系统208在执行修复时会遇到重复的或间歇性的硬件错误。间歇性错误能使修复不可能。在此情况下，文件系统208(修复模块212)不能做修复，并使卷仍处于损坏状态。若可能，文件系统208将此记录在事件日志中，试图让用户解决此硬件问题。在可重复的错误的情况下，文件系统208重试群集直到遇到坏的群集文件，并将数据处理为丢失。

带实时修复模块212的文件系统208也能看到由于运行系统的状态而引起的错误。错误的主要源应是执行某些操作的不足的池(pool)存储器。在此情况下，若可能，文件系统208在事件日志中记录该故障并终止修复。在未来某一点当再次遇到该损坏时再试图修复。

示例性方法

现在主要参考图3-5的流程图描述实现增强文件系统的示例性方法，该系统提供运行卷上检测到的损坏的实时和在线修复。该方法通常应用到上面参考图1和2讨论的示例性实施例。虽然借助流程图和与流程图的各框相关联的文本揭示了一个或多个方法，可以理解，所描述的方法的各元素不必以它们出现的次序执行，替换的次序能产生类似的优点。此外，方法不是排它的，它们能单独执行，或彼此组合地执行。所描述方法的各元素能借助任何合适的手段来完成，包括例如：通过ASIC上的硬件逻辑块或通过执行处理器可读介质上定义的处理器可读指令。

这里使用的“处理器可读介质”能是任何装置，它们包括由处理器使用或执行的存储、通信、传播、或传输指令。处理器可读介质可以是，但不限于，电、磁、光、电磁、红外或半导体系统、装置、设备、或传播介质。处理器可读介质的更具体的例子包括：具有一根或多根线的电连接(电)、便携式计算机软盘(磁)、随机存储器(RAM)(磁)、只读存储器(ROM)(磁)、可擦除可编程只读存储器(EPROM或闪存)、光纤(光)、可重写光盘(CD-RW)(光)、和便携式光盘只读存储器(CDROM)(光)等。

在方法300的框302中，检测到关于存储卷上数据的损坏。文件系统208检测该损坏。损坏能在当前文件系统请求期间或相对于该请求被检测，或者它能在以前的文件系统请求期间被检测。如框304所示，文件系统208在检测到损坏时刻记录描述该损坏的信息。在框306，文件系统产生一错误状态，表示已检测到损坏。在框308，文件系统响应于表明存在损坏的错误状态，可任选地挂起当前文件系统请求的执行。

文件系统基于检测到的损坏，使用在框308记录的信息确定修复扫描。示例的修复扫描包括：属性扫描、文件扫描、索引扫描、卷位图重建、和安全性描述符文件扫描。确定修复扫描能包括确定复杂的修复扫描，后者包括较低层扫描的集合。

在框312，由文件系统(如图2的实时修复模块212)实现修复扫描。执行修复例程以实现修复扫描。修复例程能在当前线程中执行的顶层点运行，或能启动单独/专门的线程来服务修复扫描(即，修复被记入队列中，专门的线程从中取出并完成修复)。若修复扫描是复杂的修复扫描(即，包括较低层扫描的集合)，该复杂的修复扫描的实现包括任何关联的较低层扫描。若文件系统请求是递归的请求，则文件系统展开到递归请求中的顶层请求，并对于该顶层请求实现修复扫描。

在框314处方法300从图3继续到图4。在框314，在修复扫描完成之后，当前文件系统请求恢复执行。恢复文件系统请求通常包括如所预期的完成请求。然而，若修复扫描是非一般的修复扫描，且因而尚未完成，则文件系统请求将失败，且文件系统发出一损坏状态错误。同步请求可等待，直到修复完成后再恢复。而且，若修复扫描与作出请求的应用程序的访问句柄不兼容，则请求失败，且文件系统发出一无效句柄状态错误。

在框316，接收第二文件系统请求，它与经受当前修复扫描的文件相关联。若当前的修复扫描是长期运行的修复扫描，则第二文件系统请求失败，如框318所示。若当前修复扫描是短期运行的修复扫描，在当前修复扫描完成之前，第二文件系统请求被阻断，如框320所示。

在框322，接收禁止当前修复扫描的文件系统控制(fsctl)命令(即通知机制)。从用户/管理员的输入接收这一fsctl命令。若当前修复扫描是长期运行修复扫描，该修复扫描被禁止，如框324所示。否则，完成当前修复扫描。

在框326，在实现修复扫描时检测另外的损坏。在此情况下，修复扫描能被推迟直到完成新的修复扫描，如框328所示。

在框330，在实现修复扫描的同时检测间歇的硬件错误。如框332所示，当检测到间歇硬件错误时，修复扫描停止。由于间歇硬件中错误而停止的修复扫描被记入事件日志中，如框334所示，然后用户能审阅该日志并修补硬件错误。

在框336，在修复扫描期间在文件系统数据上启动验证扫描。示例的验证扫描包括，全卷扫描、安全性扫描、文件扫描、流扫描、目录扫描、和视图索引扫描。

附录

附录提供如上结合文件系统208和实时修复模块212所讨论的损坏检测、修复调度、损坏和修复报告、以及管理修复过程的附加细节，如上所述，虽然提供NTFS(新技术文件系统)文件系统作为示例性文件系统，无意将描述的文件系统增强的应用限制到任何特定的文件系统。

应用程序兼容性

根据修复的严重性和打开句柄的方式，客户机应用程序由于NTFS损坏的修复而受到影响。若修复是快的，则由应用程序启动的任何文件系统请求在修复进行时作出等待。在这些情况下，修复操作对该应用程序应是透明的。若该修复是非一般的，则请求以STATUS-CORRUPT-XXX类错误停止。

应用程序可能需要处理修复操作的结果，它能包括在它们操纵的底层文件中无效的句柄和/或改变。修复能影响构成应用程序及使用中的任何数据文件的可执行代码。若可能，NTFS将通过USN和DirNotification事件报告那些改变。若那些改变与文件的当前访问及共享方式兼容，则该应用程序应能无意外地进行。然而，若修复不与应用程序兼容，则将看到STATUS-INVALID-HANDLE。应用程序需要处理它们的句柄不再能用于访问该文件的情况。这类似于当前的行为，其中损坏使一文件不可访问，但是自恢复NTFS文件可以访问而不必卸载和修复。

使用多个数据文件并依赖于它们之间的数据一致性的写得很好的应用程序将受到对伴有它们用来访问该文件的句柄的无效性的一个文件的改变的影响。这看来很像当前的模型，其中autochk或chkdsk能修改在它们的卷安装之间的数据文件之一。

可执行文件可能已经被修复，它们中的数据被更改。NTFS需要使当前作为映象映射的任何流无效，只要该映象作出影响该流中的字节的任何改变。运行的映象只要仍在存储器中就可以不击中任何错误。在任何请求到达文件的句柄或标记为无效的流中的NTFS，则NTFS以STATUS-INVAALTD-HANDLE标志使当前请求无效。对某些文件作出的修复能导致应用程序或甚至操作系统停止。

并发文件访问

自我恢复的NTFS必需校验正被打开或创建的文件是否由于当前运行或调度的修复操作而经受修改或删除。这一修复通常在文件本身上完成，但是存在影响目标文件的其它情况，如在父目录上的目标扫描或安全文件的重建。若正运行能影响此文件的任何修复，则只有用与读程序、写程序和删除程序共享的共享方式的打开会成功。根据正在进行修复的复杂性，不兼容的打开被阻断或失败。在一个实施例中，在修复进行时阻断所有用户文件的打开。

新文件创建

如果调用者愿意与每个人共享，新文件创建在下列修复上将阻断。否则将以着适当的错误指示而失败：

在目标创建的祖先目录上目录扫描。这包括在创建新文件的过程遍历的任何目录。

在安全性流上修复。

现有文件打开

如果调用者愿意与每个人共享，现有文件的打开在下列修复中将阻断。否则将以适当的错误指示而失败：

在正在打开的文件上的任何扫描。

为作出此打开而遍历的父目录上的目录扫描。

现有的打开句柄

自我恢复的NTFS总是具有执行修复过程的优先级。这意味着修复总被授与读、写和删除的访问权限。一旦授与此访问权限，则与此访问权限不兼容的任何现有的句柄必须被无效。NTFS将该文件的CCB标记成无效，并使该请求失败。在某些情况下，该流上的所有现有的句柄必须被无效。在那些情况下，NTFS将孤立返回该文件的SCB，并创建新的SCB，用于将来对该流的访问。

映射的文件

映射的文件的当前NT实现防止文件在存在活动的用户映射段时被截断。用户还具有通过此段对文件数据的直接访问，而NTFS无法串行化此访问。自我恢复的NTFS没有任何理由用一映射的段修改流中的数据，但可能需要截断或甚至删除该流。正是此修复截断操作与映射的段不兼容。NTFS需要孤立该数据段，在此情况下这意味着孤立所有使用该段的对象。高速缓存管理程序也使用同一段。需要无效当前在该流上的所有句柄和段，那些句柄上的任何访问将返回STATUS_INVALID_HANDLE。

简单例子-若用户使用此句柄映射该文件将会如何。校验对映射的调用并观察它是否能在文件系统回调中失败。

事件日志记入

所有损坏和由NTFS修复线程作出的后续修复的发现被记入系统事件日志和/或修复日志中。所有事件日志条目包含下列的数据的某些或全部：

·修复的描述性理由。

·文件名和到该文件的全路径。

·对该损坏的VCN(用于分配损坏)。

·文件Id。

注意，事件日志和/或修复日志本身可能被损坏。

孤立的群集的保存

将不保存孤立的群集，孤立的群集是被标记成在位图中分配但不属于任何文件的那些群集。

孤立的文件的保存

如chkdsk的行为那样操作。

映射的文件和映象

存储器管理程序不允许返回数据段或映象段的文件被截断。若修复需要截断或删除返回映射的段或映象段的流，则NTFS将使该属性无效。任何对返回属性的读或写的尝试将以STATUS_INVALID_HANDLE失败。当应用程序能用已在存储器中的数据继续运行时，此错误可能不被立即看到。因为NTFS必须使该实际的属性无效，这意味着该属性上的句柄将被无效，即使是与修复操作兼容的那些句柄。

操作锁

操作锁提出，调用程序能在任何位置本地高速缓存文件。在操作锁被打破时写回到NTFS存储的位置上可能挂起改变。自我恢复NTFS首先确定哪些句柄是无效的，以防止在修复期间发生不兼容的操作。然后它将打破操作锁并开始修复。NTFS将不在开始修复之前等待操作锁打破的确认。这简化了修复模型，并在进行修复之前不阻断系统等待用户的行动。

排它的操作锁总被打破成FILE_OPLOCK_BROKEN_TO_NOTE。NTFS允许持有操作锁的句柄完成写操作，只要校验句柄兼容性的较早的扫描成功。打破文件锁保护一定范围的文件。仅在顶层修复文件系统过滤器。若用户具有句柄，过滤器有可能总是将访问映射到不同的文件。若用户的文件正在修复，这可能不是问题。这不需要在IO层上禁止。

特殊文件

如休眠文件(hiberfile)、页面文件(pagefiile)、注册表配置元(hive)、TXFTOPS流、和故障转储(crashdump)文件等特殊文件提出独特的问题待修复。它们和文件系统密切联系，且它们的读程序与写程序作出关于它们的群集布局的假设。提供一通知机制，阻止这些应用程序的用户继续使用不再属于它们的文件的群集，并损坏磁盘。

对由MARK_HANDLE阻止(pinned)的文件也同样做。因为它们对群集完成直接I/O而不必让句柄打开(它们具有参考该文件的文件对象)，这些是特别难以处理的。不修复它们是可以接受的折衷。在页面文件中的损坏是不能容忍的。将存在分页的池的问题要处理。甚至更坏，我们自己的代码需要进页面。

事务的NTFS(TxF)

若目标文件是TxF事务的一部分，则修复需要在实际上实施改变前通知TxF。这是在文件句柄被无效的几乎同时带着占有的资源发生的同步调出。(事实上，TxF本身能做所有的句柄无效)。TxF在其自己部分将释放所有其存储器内状态用于事务(版本历史，STOP流等)，除了对TxF文件的锁定之外。一旦完成修复，修复也将被调出(callout)到TxF，所以它能在需要时继续进行其事务中止。有关的是这些调出的粒度(grannlarity)。修复不应使它们有太多负担。退出所有现有的事务可以是对覆盖该卷的特别破坏性的修复的可行解决方法。

TxF也需要处理文件不处在所期望的状态的更普通的问题，尤其是崩溃后或在中止期间。每当修复干扰其操作时，TxF将写到事件日志中。若修复对事务的完整性是破坏性的，则该事务将被中止。这是为了保证事务操作的耐用性，并让用户知道特定的改变何时为了某些理由而没有那样做。所有现有的事务的句柄将成为无效。

TOPS流和公用日志(Common Log)文件作为不能修复的特殊文件来处理。然而，TxF和公用日志需要知道如何处理在它们相关领域中的损坏。然而，理想的是那些允许被修复，因为否则它们将保持损坏状态。

在安装期间发现的损坏初始系统文件的记录

一旦卷被识别为带有效版本的NTFS卷，则文件系统确认每个初始系统文件记录。若检测到损坏，此内部文件确认能容易地扩展到整个卷的扫描。

NTFS重起失败

在运行重起时，NTFS可以击中LOG_FILE_FULL。若保存策略正确，理论上这是不可能的。这是通过重试安装而不是运行重起来处理的。这需要NTFS在后台运行全扫描，但同时该卷应可用。

属性

这些描述低层操作，尤其是对盘做出的那些行动。

基本属性

基本属性是在文件记录中的属性。它能是在VCNO上的常驻属性、非常驻属性，或描述一段非常驻流的任何属性。

盘上的内部属性不一致性-去除除在VCNO处用户数据属性外的任何非常驻属性。使那些属性为零长度。去除除了用户数据属性外的任何常驻属性。使那些属性为零长度。需要确保更新属性列表。需要确认余下文件仍然有效。从可能包含属性的任何索引中去除属性。

盘上与SCB的不一致性-首先确认盘上属性，并作出必要的改变。然后用正确的盘上改变更新SCB和FCB。

仅在存储器内结构中的不一致性-再次从盘上更新SCB和FCB。

分配长度高于支持的值。我们可对照映射对和最高VCN值来验证此值。

复杂属性

复杂属性是构成完整的NTFS属性的所有基本属性的组。

内部属性确认校验所有这些属性是自身一致的。若是，NTFS将更新SCB和FCB以反映这点。外部属性确认涉及对所有属性扫描MFT。因为此涉及MFT的全扫描，实在没有任何理由不作外部文件确认。

以下错误表明复杂属性的损坏：

对越过分配大小的文件片段存在基本属性-去除不需要的片段。

在复杂属性内丢失属性-首先作内部属性确认。若这判定成一致的属性，则更新SCB以反映这一点。否则移动到外部文件确认。

不一致的SCB值-做内部属性确认。

MCB具有长度0的范围-做内部属性确认。

属性内容

自我恢复的NTFS确认具有NTYS元数据的属性，或具有NTFS元数据的属性的部分的内容。例如，重新分析(reparse)点包含固定数据和用户定义的数据。NTFS不作任何努力来保存或确认任何属性的用户部分。

在NTFS元文件中特殊属性的内容确认在其它地方描述。

非常驻属性

在引导文件外的文件中的LCN零-属性是无效的，应设置成零长度或删除。此后作内部文件确认。

$STANDARD-INFORMATION(标准信息)

无效的$STANDARD-INFORMATION-做内部文件确认。重建标准信息。

$ATTRIBUTE-LIST(属性列表)

属性列表长度切断现有的属性-做外部文件确认。

属性列表具有零长度-做外部文件确认。

属性列表具有不在文件中的条目-做内部文件确认。

属性列表丢失文件记录中的条目-做外部文件确认。

$DATA(数据)

$DATA属性-在修复损坏的用户数据流时，NTFS只采取某些行动。如果需要存在零长度属性时创建它，若它当前存在且被破坏则截断到零，或全部删除。

$REPARSE-POINT(重新分析点)

无效的$REPARSE-POINT-从文件和从重新分析索引中去除属性。更新FCB/SCB以表明不存在重新分析点。

$Reparse属性-只能在目录上的接合点，且该目录必需空。$Reparse属性及$EA属性不能均存在于同一文件或目录。重新分析标签是DUPLICATED-INFORMATION的一部分。

$EA和$EA-INFORMATION(RA信息)

$EA和$EA-INFORMATION若都存在则必需一起出现。EA信息也存在于该文件的DUPLICATED-INFORMATION之中。对一文件的EA必需与在目录条目中的EA信息一致。内部EA确认验证EA和EA-INFORMATION是有效属性、EA是构造良好的且目录信息中的EA信息匹配。此外，在文件中不存在$REPARSE属性。

EA属性丢失-做内部EA确认。

索引

属性上的索引在对应于文件中的属性的索引中具有一条目。例子是文件名、重新分析点和对象id。下面某些错误应用到所有索引，但专用于索引的错误只应用到属性上的索引。

这些索引的内部确认涉及验证索引是形式良好的且适当地排序的。此外，索引中的条目在文件中具有对应的属性。

外部确认涉及做MFT的全扫描，以寻找对应于此索引的条目。

索引头部

索引头部偏移点在缓存器之外-通过全MFT扫描重建索引。

头部指向无条目处-用全MFT扫描重建索引。考虑基于打乱(Shuffling)的b树(btree)的优化，或通过步查所有索引缓冲区并添加条目到拟构建的新索引，在适当位置重建它。

在最后索引条目之前击中最终记录-用全MFT扫描重建索引。优化包括只孤立越过虚假的终点记录的条目，或测试是否有另外的终点记录。

索引缓冲区

在IndexBlock中设置较高的32位-丢弃此索引并用MFT扫描重建索引。考虑如果内部校验表明索引条目是有效的，则忽略无效位并复位成零。

在IndexBlock数的较低32位中的不正确的值-通过全MFT扫描重建索引。只考虑基于IndexBlock字段中的损坏的优化。这能在将此设置到期望的值之后通过内部索引确认来完成。

无效的头部签名-通过全MFT扫描重建索引。只考虑基于在签名中的损坏的优化。

无效的USA头部和数组-通过全MFT扫描重建索引。

带空叶节点的索引缓冲区-做内部索引确认。

索引条目

内部索引条目长度延伸到条目长度之外-去除该条目，做内部索引确认，然后做全MFT扫描寻找孤立块。若NTFS能从索引中恢复文件引用，则MFT扫描是空操作。

试图添加已经存在的条目-这可能表明在逻辑中的一个错误。应该已存在校验，来看是否存在该条目。若有一个真实的问题，则修补方法是做索引的内部确认并随后做MTF扫描以搜索孤立的条目。

NODE值的不匹配-索引缓冲区中的所有条目需要匹配值。通过全MFT扫描重建索引。考虑基于缓冲区上任一条目中节点位中的损坏的优化。还考虑当前条目能否被去除，能否完成内部确认。这使得在MFT扫描寻找孤立块的同时索引处于可用的状态。

无效的索引条目长度包括长度0-通过全MFT扫描重建索引。考虑提取单个坏条目的方法。若这是叶节点，这可以通过舍弃在索引存储段中的余留条目和只寻找孤立块的MFT扫描来完成。

期望的索引位图丢失-若所有其它索引属性都存在，则能通过步查b树来重建位图。若此失败，则需要全MFT扫描。

索引缓冲区只包含终点条目-用全MFT扫描重建索引。考虑基于打乱的b树的优化，或通过步查所有索引缓冲区并添加条目到正构建的新索引在适当的位置重建它。

不平衡的b树-用全MFT扫描重建索引。考虑基于打乱的b树的优化，或通过步查所有索引缓冲区并添加条目到正构建的新索引在适当位置重建它。

记录分配位图

当尝试置位时位已经被置位-不初始化记录分配包，并从盘重新读。若此损坏位在重新初始化记录分配包的同一例程中找到，则是硬错误。

在尝试清零时位已经被清零-无错误，但再次将清零位的动作记入日志。

基本文件记录

基本文件记录是当前标记为IN-USE(使用中)的任何文件记录。它能代表整个文件或仅是文件的某些属性。

属性跨越文件记录边界-插入越过最后一个有效属性的SEND(发送)属性。此后需要完成文件确认。

从CheckFileRecord(校验文件记录)中找到损坏记录-确认每个属性，确保这些属性被正确地放置，确认头部值。若结果甚至不包含一个属性，则将文件记录标记为不是IN-USE。做此属性有关的文件的内部文件确认。

IN-USE位未被置位-若存在对此文件记录的外部引用，则校验MFT位图是否被置位。若位被置位或其它指示说明此文件记录应是正在使用中，则复位文件记录中的该位。否则将该记录标记为未使用，且做内部文件确认。若需要，到外部文件确认。

文件签名损坏-删除此文件记录中所有属性。若文件已知，做在此文件上的全文件确认。若文件未知，则可能需要做全扫描，寻找引用此文件的索引条目。若已找到，则重建文件的已知片段并生成通知。考虑基于将损坏限制到文件签名的优化。

BAAD文件签名、坏的USA头部、坏的偏移字段-删除此文件记录中的所有属性。若文件已知，在该文件上做全文件确认。若文件未知，则可能需要做全扫描，寻找引用此文件的索引条目。若找到，则重建文件的已知片段并生成通知。

坏文件记录校验-删除此文件记录中的所有属性。若文件已知，在该文件上做全文件确认。若文件未知，则可能需要做全扫描，寻找引用此文件的索引条目。若找到，则重建文件的已知片段并生成通知。

完整文件

完整文件是所有的基本文件记录，对非常驻属性和外部引用的外部分配。盘上的大多数文件是用户文件或用户目录。系统文件的特定属性在其它地方描述。文件和目录具有下列属性：

MFT位图对文件中每个文件记录置位了对应的位。

对该文件的所有文件记录是形成良好的，并使IN-USE位置位。

基本记录对其基本记录具有0。

其它记录参照基本记录。

VIEW-INDEX位未被置位。

FILE-NAME-INDEX表示这是用户目录。

文件具有下列需要的属性($STANDARD-INFORMATION，$FILE-NAME)。

$FILE-NAME带着DOS或NTFS位存在，则必须存在带着其它标志的对应的$FILE-NAME。

用户文件必须具有一个未命名的$DATA流。用户目录必须具有文件名$INDEX-ROOT以及其它需要的索引属性。在任何用户文件或目录中只有这些中的一个能存在。

下列属性可能存在($ATTRIBUTE-LIST，$OBJECT-ID，$SECURITY-DESCRIPTOR，$REPARSE，$EA-INFORMATION，$EA，命名的$DATA，$LOGGED-STREAM)。具有重复制的名字的$DATA流是不允许的。

内部文件确认假设所有关于文件的信息是在文件记录中，则NTFS能通过步查该基本文件记录和属性列表(如果有的话)来找到。它本身不关心从外部到此文件的反引用(即目录中到此文件的入口)。

下一层校验验证每个索引的属性和安全性引用具有有效的对应外部数据。

外部文件确认步查整个MFT，寻找属于此文件的文件记录。

下列错误对文件是特有的。

文件被标记为目录，但丢失$INDEX-ROOT属性-通过查找未命名的数据流和/或其它$INIDEX属性校验目录位是否不正确。若它仍然看似为目录，则创建空目录并扫描MFT寻找目录中的其它文件。删除其它$INDEX属性。

对用户文件没有有效的链接-需要校验是否存在有效的专用链接。若需要插入名字，则将它放在根部中FOUND目录。

无$STANDARD-INFORMATION属性-大多数值能从文件的其余部分推出。将其如更新时间标记、属性和安全性那样处理。

属性存在于文件中但不在索引中-将对应的条目放到索引中。可能在索引中已经有冲突的名字(即文件名)。在此情况下，必须在‘Found’目录中创建该文件的链接。

不能找到在其它地方索引的预期的属性-可能的话，插入对应的属性，只要它与文件的现有状态不冲突。否则去除在索引中的该条目。在文件上做内部校验。

不能找到预期的属性(未在其它地方索引)-做内部文件确认并更新SCB/FCB以匹配改变。

丢失需要的属性列表-做全外部文件确认。

丢失长/短名字对的一个属性-首先用孤立块成员在目录中扫描，并观察是否存在其它名字。若是，将其加入文件。若长名存在并是有效的短名，则转换到长/短名的文件名。若长名存在但不是有效的短名，则生成一个有效短名。若存在-短名，则只要使它成长/短名。

日志文件损坏

不能启动日志

在重启期间不能读

硬件故障和数据损坏错误

根目录

根目录具有所有其它目录的属性，并还有：

它包含用于本身的一个条目。

它对每个系统文件具有一个条目。

它使SYSTEM和HIDDEN位置位。

其自身的名是“.”。

它永远是目录。

卷位图

试图置位已经置位的位-这应是硬故障，因为若那些位来自高速缓存信息，NTFS总是做一次重试。

试图设置LCN 0为空-在该文件上做内部文件确认。若该属性不应具有LCN0，则将其设成0长度。

安全性文件

损坏的描述符-校验后备描述符。若仍然损坏，则需要去除损坏的描述符并步查MFT以寻找匹配的文件。正确的次序是先步查MFT并改变安全性。保存损坏的描述符表，并不允许在此类型上匹配。

孤立的描述符-能够被去除，但需要向不需要此条目的TXF确认。

特定的错误包括：

关键字长度不是在安全性ID索引中的SECURITY-ID的大小。

数据长度不是在安全性散列索引中的SECURITY-DESCRIPTOR-HEADER的大小。

属性定义文件

丢失$DATA属性-改写属性表。这能在合适地方完成而不公告。然而，在需要首先修复的层叠损坏被击中的情况下，NTFS需要跟踪这在进行中。

重新分析点文件

重新分析点文件包括单个索引“$R”。该索引将重新分析点标签映射到Ntfs文件ID。文件应具有所有形式良好的属性和文件记录。重新分析点具有下列属性：

在头部中VIEW-INDEX位被置位。应不令FILE-NAME-INDEX位被置位。SYSTEM-FILE位被置位。

文件名是$Reparse并包含在$Extend目录中。

它没有负责的份额。

它具有System/Admin安全性描述符。

它只有下列属性($STANDARD-INFORMATION，$ATTRIBUTE-LIST(如果需要的话)，$FILE-NAME，$R的$INDEX-ROOT，$R的$INDEX-ALLOCATION和$R的$BITMAP)。

$INDEX-ROOT属性应表明这是视图索引，且核对值是正确的。

内部重新分析文件确认校验上述是存在的且只有这些存在。索引应是形式良好且正确地排序的。它还确认$R索引中的重新分析标签关键字是有效的，且它们指向的文件ID落在MFT的有效部分中。若已知索引是损坏的(实际修复正在进行)，则访问该索引的请求将被阻断或失败。若确认正在进行，但未发现损坏，则在正常同步约束下继续进行访问索引的请求。

下一层校验采用索引中的每个条目并验证所引用的文件Id实际上是使用中的用户文件，且它具有对应的重新分析属性且该性包含有效的重新分析点。文件上的重新分析标签应匹配在该重新分析点中的标签，并匹配SR索引中的标签。

最后的校验层是在不具有索引中对应的条目的文件中寻找孤立的重新分析点属性的全MFT扫描。

下列错误是$Reparse文件及合适的修复专有的：

在$Reparse文件中不能找到对应的条目-对具有孤立的重新分析点的文件做内部确认。然后做$Reparse文件的内部确认。最终在需要时将重新分析点插入到重新分析索引中。

分页文件

对分页文件执行I/O的任何故障对系统是致命的。这里只能做有限的修复。

映射对未完全加载-使当前请求失败并指派工作项。做该文件的内部确认，并随后仔细地将分配信息从盘加载到MCB。这能导致系统失败。

MFT构造

文件记录0看来是可用的-做MFT扫描以重建MFT位图。

对在MFT中孔(hole)的引用-产生对孔的群集。确认指向未初始化的文件记录的任何文件。

MFT和MCB中的MFT映射

不能找到第一映射-通过阅读MTF和Mirror(镜象)中的初始文件记录来验证映射。若不能找到有效的条目则做全磁盘扫描。

MFT位图映射

$BITMAP不存在-做MFT扫描并重建位图。将此插入到$MFT文件中。

失败的中止

失败的中止能使卷处于损坏状态。若能标识涉及在事务中的各单独的流，则有可能仅在它们上进行修复。否则可能必须做全卷扫描。某些错误可以安全地忽略，因为在用户再次访问它们时NTFS检测此问题。

当处理中止时可能发生下列特定的错误：

无效的日志记录校验。

重起失败

运行重起的失败能使卷处于无效状态。通过完成安装，但使该卷标记为脏，或调度-全卷修复，NTFS能从此状态恢复。也可能简单地使该卷处于损坏状态并在遇到时允许各个错误被检测和修补。

初始化重起状态

在初始化重新起动状态时会出现下列特定的错误：

在日志中的LFS结构中的内部不一致性。在这些情况下，LFS当前产生损坏状态。

阅读NTFS重起记录的错误。

阅读NTFS重起记录中重起表的任一日志记录的错误。

对任何写到盘上的重起表的无效NTFS记录头部。

写在日志记录中重起表的损坏。

属性名条目具有对底层打开属性条目的无效索引。

运行分析遍(analysis pass)

在运行分析遍时会出现下列特定错误：不能从盘上读日志记录。从盘上读出无效的日志记录。

初始化脏页表

在初始化脏页表时会出现下列特定错误：

脏页条目指的是无效的属性索引。

脏页条目指的是不存在的属性。

运行重做(Redo)过程

在运行重做过程时会出现下列特定错误：

不能从盘上读日志记录。

从盘上读出无效的日志记录。

日志记录指向无效属性索引。

日志记录指向不存在对应属性的属性索引。

这里描述结构上的实现。包括在发现进一步的损坏时的锁定和行动。

日志改变的最简单方法是将整个文件记录、索引缓存，非常驻属性记入日志。

若正在重建索引，则其中的条目能作为有效来处理。若在正常处理时我们发现孤立块，则它能在进行全扫描的同时被简单地添加。然而同时我们必须阻止添加用户生成的条目。

MFT重建

全MFT重建涉及在卷上做群集的全扫描，以搜索MFT文件记录。

NTFS将对何时发生此搜索以及识别哪些‘文件记录’施加限制。NTFS能遇到一种情况-另一NTFS卷的映象作为文件储存在当前卷上。而且当前卷能包含快照信息或从整理碎片操作中使MFT记录失效。

卷必须是NTFS版本4.0卷或更新版本。这意味着新文件记录总是具有嵌入到头部的文件记录号。

NTFS完成作为升级过程一部分的扫描，以将正确的文件记录号和卷识别符储存到每个正使用的文件记录中。一旦完成此扫描，则在卷DASD文件记录中设置一标志，表明重建整个MFT是可能的。

MFT重建包括下列步骤：

将NTFS标识成文件系统类型的引导扇区确认。注意-若不能从引导扇区确定群集的大小，则NTFS必须基于默认的大小建立映射，并然后在以后确定真正的群集大小。在初始识别阶段能使用备份引导扇区，以提供MFT位置和群集大小的可能确认或正确的备份拷贝。

试图通过由引导扇区指向的MFT记录构建全映射对。若MFT不能以此方式重新构建，这能导致找不到记录。在NTFS从零开始重建MFT的情况，这是预想得到的错误。

若从上述步骤，映象对未完成，则启动盘扫描。开始阅读盘以寻找可能的文件记录。使用潜在文件记录中的USA签名、文件记录号和卷标识符。可能的虚假击中能包括：

·在MFT镜象中的文件记录

·来自MFT整理碎片的旧MFT数据

·在重新格式化之前来自卷的先前实例的失效数据

·卷快照数据

·作为文件存储的NTFS盘映象

·在用户文件中看似有效的MFT记录的数据(可能是恶意的)。

当NTFS遇到这些记录时，它将按卷标识符字段将它们组合到卷后选者中。它将构建可能的卷的单独拷贝并在可能时消除它们。当找到每个记录时，其使用默认群集大小的位置被存储在该卷标识符的MCB中。在冲突的情况下(在MCB中的该位置处已经存在一条目)，NTFS检查页面上的LSN，并使用带较高LSN的页面。MFT镜象中的文件记录看来是有效的，但在认为它们是MFT的一部分时却驻留在错误的位置。对于在这点遇到的每个后选卷的前0×10个文件记录，NTFS保持映射关系的两个拷贝。若遇到描述MFT本身的文件记录，则NTFS将扫描文件记录，寻找$DATA属性，并记住在单独的MCB找到的部分映射关系。

当卷扫描完成时，NTFS能具有多个卷后选来解决。对每个后选卷，NTFS已从卷扫描保持了下列：

·卷标识符-存储在卷DASD和文件记录中

·来自自描述MFT文件记录的部分MCB

·来自在盘上找到的MFT文件记录的部分MCB

·对于在镜象范围中替换的可能有效MFT的部分MCB

然后NTFS需要分析这些后选者的每一个，以找出对此卷是实际的MFT的那些。若NTFS对MFT或MFT的镜象能找出文件记录，则它能确认它们是否在由它们自己的映射对所描述的偏移处。这是第一层认证。若只有一个卷后选，则NTFS能认为，所有找到的有效文件记录属于该卷。

在重建MFT或某些系统文件同时，NTFS可能需要可用的空闲群集的某些知识。这可以在卷位图流中不存在有效$DATA属性的时间点上。卷的大小能使得不可能在存储器中存储位图的完整拷贝。替代地，NTFS能扫描已知的文件记录并寻找属于卷的位图的子集的分配的群集。这部分信息能用于分配新的群集给MFT、卷的位图和日志文件。

分配足够的空闲群集以填满MFT中的孔。添加这些群集到MFT的映射信息，并用未初始化的文件记录初始化实际的群集。

MFT位图重建

若MFT位图属性丢失，则NTFS能从零开始重建它。这能在为构建MFT的映射对的NTFS扫描发生之后完成。在属于MFT位图的群集丢失的情况下，NTFS采取下列步骤：

·计算该位图需要的群集的数目。

·寻找必要的群集。这能涉及扫描已知MFT记录寻找空闲的群集。这可能需要按范围的单独扫描。

·对此构建映射信息，并将其存储在MFT位图的Scb中。

·初始化位图成全部为0×ffffffff。

·扫描MFT中的已知文件记录，寻找未初始化的记录，并对MFT位图中的那些位清零。

·使必须置位的位置位，即使对应的记录尚未在此状态。这包括前0×10个系统文件记录。

MFT位图现已准备好进行作为全在线chkdsk扫描的一部分的正常的验证过程。

MFT镜象重建

若MFT镜象文件丢失，在MFT完全重建之后从MFT将其重建。

日志文件重建

在修改NTFS元数据时使用NTFS日志文件。日志文件需要被初始化，并在做出需要记入日志的修复时可用。若日志文件损坏，则它必须在使用日志进行的任何修复之前修复。注意，所有必须的是该日志和SCB的映射信息指向盘上的有用位置。该日志的文件记录能在此之后修复。

在日志文件中有若干类型的损坏。这些能是内部和外部的：

描述日志文件的损坏的元数据(外部)-这是当NTFS丢失日志文件的文件记录或描述该日志的元数据损坏时的情况。在这些情况中的每一种，NTFS需要找到足够的群集用于日志文件。然后NTFS用此映射构建Scb，并初始化该日志的群集。

该日志文件中的损坏数据(内部的)-若这在安装或重起期间发生，则NTFS能将整个日志处理成损坏的并将其重新初始化。若该卷已是活动的，则NTFS能忽略该错误，但将作为当前事务一部分的任何文件标记成损坏的，并在其上执行验证扫描。

重新初始化日志文件涉及下列步骤：

·将模式0×ffffffff写到整个日志。这将保证，已出现在那些群集中的失效数据不扰乱NTFS。

·将卷上最高的已知LSN传送到LFS。然后LFS初始化日志文件，使得它生成高于此值的LSN。

全卷修复

这对应于chkdsk当前做的全扫描。

卷的可用性

在管理员已经在安装卷上启动了此请求的情况下，NTFS卷可能是可用的。在NTFS检测到安装路径上严重的问题的情况下，在该卷处在可用的状态之前安装被阻断。

若用户在正进行修复扫描的卷上是活动的，则他能遇到阻止其操作完成的损坏。若存在可绕过的可用方法，则用户的请求能完成。否则他的请求被阻断在全扫描之后。

预备状态

为完成全扫描，NTFS必须具有某些资源。在全扫描开始之前下列必须准备好：

·全MFT的映射信息(寻找在存储器中MCB信息和在自描述MFT文件(如果可用的话)的映射对之间的不一致性)

·MFT位图的映射信息

MFT镜象的映射信息

·NTFS日志文件的映射信息

·NTFS卷位图的映射信息

·在卷的位图可疑的情况下已知可用的空闲群集的某些高速缓存

·从Bad Cluster(坏群集)文件(如果可用的话)知道的坏群集。若被请求，来自卷扫描的坏群集列表。

·可使用的大写表

·可使用的属性定义表。

初始MFT扫描

NTFS通过由映射对描述的MFT记录扫描。由于在存储器中NTFS能保持多少信息的限制，可能需要作出若干次扫描。第一次扫描对每个文件记录做详细的工作。后续扫描应该只需要步查通过每个MFT记录，寻找有关所需信息类型的数据。在此阶段结束时下列应为真：

·验证MFT位图对应于MFT中文件记录的状态。这意味着所有IN-USE文件记录在MFT位图中被置位，对可能损坏的需要的系统文件记录的位也如此。这可能需要做多次扫描，取决于MFT位图的大小。

·索引的属性的数目的计数。这包括文件名属性、重新分析属性和对象ID属性。这在以后校验孤立块时使用。

·标记成IN-USE的所有文件记录被正确地构筑，虽然在此点可以不校验所有属性的内容。

·基本文件记录和子文件记录通过良好构造的属性列表连接。

·用户文件和目录包含未命名的数据流或文件名索引。可能此处需要插入零长度流或索引。

·系统文件包含基本需要的属性，虽然属性的内容可能还不正确。该系统文件的无效属性(如果存在的话)被去除(即MFT不具有EA)。

·即使内部数据尚未完全核实，需要的系统文件存在。

·文件内部是一致的。这意味着在各个属性上DOS风格的文件属性匹配NTFS属性位。EA和重新分析位匹配那些属性的内容，EA和EA-INFORMATION一致。

·还校验，若存在多个文件名属性，验证它们不是对同一目录的多个匹配条目。

·分配的群集的精确快照反映在卷的位图中。这只可能是全位图的子范围。它可以采取若干次通过MFT来重建整个位图。

·找到并修复交叉链接。为分配给其它流的群集中找到的属性分配新群集。

索引修复扫描

这包括步查MFT，寻找带有置位的INDEX位的基本文件记录。然后确认索引。在此扫描结束处下列应是真：

·索引被很好地排序。

·索引条目形成良好。无效条目被去除，并期望在孤立块扫描中找到。

·索引缓存是形成良好的。

·余下索引条目的对应属性保证存在。

·在初始阶段找到的索引属性的计数在每个确认的条目上递减。现在此计数反映其对应的条目尚未找到的属性的数目。

·索引的$INDEX-ROOT具有正确的核对规则和默认的大小。

·$BITMAP和$INDEX-ALLOCATION反映实际被使用的存储段。

孤立块扫描

NTFS在做上述全卷扫描时维持索引的属性的计数。因为索引被确认，因此当在索引中遇到各个条目时计数递减。注意，若用户在此系统中是活动的，并添加条目到索引中，则全局索引计数需要被正确地偏移。全索引扫描顺序地步查通过MFT，寻找索引。这意味着NTFS能维持所有索引条目已被确认的点。若用户先前在MFT中改变-目录，则索引计数不需要更新。若在此点之后他们正改变在目录中的条目，则取决于正在做的操作，索引计数需要递增或递减。

此扫描仅当在上述最初两次扫描之后仍有余下的未解决的索引的属性时才需要。它涉及再次步查MFT并搜索索引的属性。对每个找到的条目，NTFS将观察有关的索引并验证存在对应的索引条目。此扫描能在NTFS找到匹配数量的孤立块处被缩减。

系统上活动的用户也能遇到孤立块。例如在删除文件操作期间，NTFS能找到没有对应索引条目的属性。若全卷扫描正在进行，则孤立的属性能被去除，且由该卷扫描所保持的索引的属性的计数递减。

NTFS将更正这次发布的版本号。向后兼容的NTFS将作为服务包升级对WinXP系统可用。向后兼容的NTFS支持由于版本升级的改变，并在WinXP系统启动时保持卷的一致性。对于这次发布的盘上版本的改变包括：

储存在卷DASD文件记录中的新版本号。

·对ATTEMPT完成初始扫描来更新所有文件记录，以将文件记录号包括在文件记录头部。属性列表的限制或盘空间的不足使这对某些卷不可能。卷DASD文件记录中的标志表明扫描已完成。

·与卷关联的单独的标识符也存储在卷DASD文件记录中及所有文件记录的头部中。这允许对MFT记录的全卷扫描以正确地定位属于给定卷的记录。这将处理下述情况，即，它们可能是另一卷的盘映象或包含在该卷上的文件中的此卷的快照。若卷DASD文件记录丢失，则NTFS能通过记录MFT本身的文件记录具有其自己的映射信息而试图解决不一致性。若在卷上存在多个MFT文件映像，则可能其中只有一个按照其自已的映射被正确地定位。

·若可能，扩展MFT镜象以覆盖MFT的前0×10个记录。

·若版本号超过已知的版本号，Chkdsk(离线和在线)将尊重盘上的属性定义表。通常，当主要版本号很少进展时这意味着次要的版本号。

·最近安装卷的系统的版本号存储在卷DASD记录中。

·更新所有系统文件以使用新的安全描述符。

Chkdsk相关的Fsctrls

等待当前修复结束

当前修复是什么

当前修复到什么程度

取消当前修复

取消当前及挂起的修复

启动扫描(什么层次的扫描，RO或W)

ChkDsk有关的状态码

由于修复正在进行而失败的操作

由于检测到损坏而失败的操作

由于修复文件已导致当前的句柄被无效而失败的操作

重要的是在长扫描运行时返回STATUS-CORRUPT而在扫描结束时用户的句柄还有效的(可能的)瞬态错误，和表明由于发现损坏和后续的修复而使用户的句柄不再有效的STATUS-CORRUPT之间进行区分。

注册表设置

报告损坏，但在用户启动前不运行在线chkdsk。以此方式，在任何有效文件/目录上无系统停机时间。

运行修复操作的线程

NTFS将停掉专用的工作线程来执行修复操作。这将在清除具有修复工作项的IrpContext的点上完成。该线程以与由关键工作队列使用的ExWorker线程相同的优先级运行。NTFS在调度新线程之前核查该线程是否已经被调度或运行。

若调度工作线程失败，则NTFS具有排队的工作项但无线程运行。在成功地调度该修复线程后，NTFS将NtfsData标志置位，若NTFS检测到存在工作项但无修复线程在运行，则它继续试图在每个模糊的校验点间隔期间调度线程。

NTFS使用排队到全局工作队列的修复项目的计数以判定是否需要调度工作线程。此值在工作项被排队之前递增，而在工作项完成之后递减。从0到1的转移表明，线程应当由递增该值的线程停止。从1到0的转移表明，当前的修复线程能够退出。调节该值并测试先前的状态的互锁操作能用于确定必要的线程改变。

挂起修复队列的NtfsData

NTFS使用队列来记入新的工作项，并组织挂起的工作。

首先，这是工作项最初被记入的位置。这些工作项描述找到的损坏及可能要做的修复工作的类型的暗示。这些工作项是基于何时检测到并记入了损坏来排序的。在工作项中还有一顺序号，表明何时检测到损坏。工作项最初被排队到此队列的头部。

队列的第二个使用是保持在某些其它操作结束之前被阻断的修复操作。等待某些其它修复而要阻断的工作项被排队到队列的最后。如果此新修复将修补原始工作项的所有损坏，则在阻断的工作项中还存在对需要首先完成的工作项的引用。作为例子，考虑我们正确认一文件，并发现属性列表被损坏并丢失。文件修复需要推迟到存在寻找属于给定文件的所有文件记录的全MFT扫描之后。初始工作项在执行依赖的修复的同时被重新排队到工作列表中。

当完成-工作项时，NTFS修复线程将监听工作队列，寻找能作为刚完成的修复的附带效果完成的项。这是通过遍历列表，寻找涉及刚完成的工作项的条目来做到的。在此扫描期间，NTFS也将寻找在刚修复的同一对象中检测到的其它损坏，并完成关联的工作项。考虑在一个文件上的修复在进行时在该文件的另外属性中找到的独立的损坏。在文件确认完成时，所有属性必须是正确的。在该文件中没有理由启动另外的工作项。NTFS使用与修复项关联的顺序号来判定在完成文件修复之后是否找到新的损坏。

修复同步的结束

当工作项完成，则发信号通知工作项中的事件(如果存在的话)。在发信号通知事件之后，修复线程递减在该工作项中的引用计数，且若转移到0时删除该工作项。等待该事件的用户线程也递减在该工作项中的引用计数。若在此点计数达到0，则正是该用户线程负责删除该工作项。

取消用户IRP或用户线程

能有这样的用户线程，在它能执行之前必须等待修复操作的完成。在NTFS顶层，我们能通过在工作项中的通知事件等待修复操作。NTFS必须等待而不阻断内核模式APC，使得用户能取消该线程或当前的IRP。若在等待事件时返回的状态码表明，系统正取消当前的线程，则NTFS能以STATUS-FILE-CORRUPT-ERROR完成当前的IRP。NTFS使用策略来与取消IRP同步。还能递减在修复工作项上的引用计数，且若计数达到0就删除它。

NTFS还允许取消在进行修复操作时保留的任何IRP。NTFS使用IrpSP.Information字段表明，它在此IRP上接收-取消，并在撤消例程中，而不是在等待工作项通知事件的点处完成该IRP。

取消修复工作

自恢复NTFS做片断中的任何修复。它不需要通过在扩展的时间段中保留资源而在系统中触发任何重要的超时。它将保持当前工作项的状态信息，以便知道接下来做什么。在工作的每一时段开始时，将校验用户是否已表明当前的工作项是否应被取消，或正修复的卷是否已被卸载。若两者的任一个为真，则修复线程将中止当前的修复及任何表明的其它修复。然后NTFS将处理每个工作项，并发信号通知该通知事件以及完成与该修复关联的任何IRP。

在运行系统中的损坏检测

在检测到损坏时，NTFS分配-修复工作项并按损坏的细节初始化它。该工作项附加到顶层IrpContext。这需要步查通过线程栈上下文的链。这样做是因为修复需要与代表用户发出的Irp相关联。IO栈需要展开到发出顶层请求的点。当检测到损坏时，NTFS需要核查，对它是否已经记入了一个工作项。这意味着校验包括在损坏中的FCB或SCB的状态，以观察是否已记入了一个覆盖此损坏的工作项。

修复工作项

NTFS在全局列表中保持少数的工作项，来处理由于INSUFFICIENT-RESOURCES而分配失败的情况。工作项在结构中可具有下列字段：

NotificationEvent-用于发信号通知此修复工作已经完成的任何等待的线程。

Reference Count-表明此工作项仍然存在的理由的数量。此值最初被设定为1或2。一个引用是由于要由工作线程完成的修复工作。若存在正等待该工作项完成的线程，则设置另一引用。在发信号通知上述NotificationEvent之后，工作线程递减该引用计数。等待线程(如果存在的话)在不再等待修复的点处(修复完成或等待线程被取消)递减此引用。无论哪个线程将引用计数转移到0，将负责删除该工作项。

FileReference-这表明哪个文件实际上被损坏。值MAXULONGLONG表明不存在正被修复的文件损坏。若该值不是MAXULONGLONG，则该文件的FCB将具有引用，以防止它离开存储器。

FileRecordReference-这表明哪个文件记录实际上被损坏。值MAXULONGLONG表明没有已知的损坏的文件记录。

AttributeOffset-这是已损坏的上述FileRecord中的偏移。值零表明没有已知的损坏属性。虽然这不意味着不存在需要被校验的属性。例如，FTNS已发现丢失一属性。

AttributeTypeCode-表明需要被校验的属性类型码。

AttributeName-需要被校验的属性名的UNICODE串。

NTSTATUS-表明修复是否成功完成的状态。

IRP-这是由用户发出以启动修复操作的IRP。这也是在检测到损坏时正在处理的IRP。在下面Flag字段中的信息表明这是哪种情况。在第一种情况下，在修复完成后，IRP也完成。在第二种情况下，在修复完成时重试IRP。利用此第二种情况的唯一机会是若NTFS已经向用户返回STATUS PENDING，在此情况下必须将IRP记入到ExWorkerThread。若IRP未被用户的动作取消，NTFS将用取消IRP的旋转锁(spinlock)串行化以完成此工作。

Flags-表示关于要做的修复的更多的细节。还表示IRP(若存在)是用于通知还是要被重新发出。通知IRP由用户发出来启动扫描。

LIST-ENTRY-工作项的全局队列。

RelatedWorkItem-若存在，表示一旦完成了RelatedWorkItem，则此工作项能完成。RelatedWorkItem作为在处理此工作项时发现损坏的结果而被创建。

SequenceNumber-与此工作项关联的序号。用于加上说明在修复完成后是否发现损坏的日期栏(dateline)。

非致命性损坏

在某些情况下NTFS发现损坏，但不需要将当前请求的完成推迟到修复完成之后。在此情况下，NTFS生成一记入到顶层的工作项，但能继续处理当前的请求。这是在修复发生的同时绕过损坏工作的策略的情况。若工作能内嵌地启动，则在将修复工作项附加到顶层IRP-CONTEXT之后，当前的请求能继续。这里的一例是损坏的安全性扫描符。能生成修复项，但在修复完成之前当前的请求将使用当前文件的SYSTEM/ADMIN描述符。

原地修复

某些修复不需要将工作项记入到顶层线程。某些修复能在当前运行的操作中完成。例如，若NTFS正释放卷$BITMAP中的一个比特，并发现该比特已被清零，则没有任何需要记入的工作。自我恢复NTFS的初始版本偏爱简单模型胜于优化，所以即使修复能内嵌地完成，仍可以选择记入。

用户启动的修复

NTFS将生成被排队到工作线程的工作项来做实际工作。这里，用户请求和用户线程将使用对与修复操作交互的常规用户请求相同的等待技术。

通过FileID句柄打开

为了找出打开文件的所有句柄(和CCB)，我们还需要找出已由FileID或ObjectID打开的那些。CCB被排队出支持打开的SCB。NTFS将步查一特定流或特定文件的所有流的CCB，寻找CCB来无效。

测试考虑

·如何在线生成损坏。

·如何确认修复。

·如何驱使Ntfs发现损坏。

·验证Usn和DirNotify通知。

·验证Fsctls。

·验证修复后的句柄行为。

·生成引导损坏

·在运行修复时验证等待和取消行为。

·用于测试何处没有完成修复但报告了在扫描中找到的损坏的可能修复方式。这将对测试给出一机会来确认NTFS正寻找损坏。

并发修复操作

NTFS可以在单独的线程中同时发现诸损坏。自我恢复NTFS的初始版本将修复记入到单个工作队列，并在需要时在专门产生的线程中处理它们。自恢复NTFS的未来版本允许修复操作在单独的线程中运行，尤其是在检测在损坏时代表用户运行的线程。此策略仅对有限范围的修复适用。明智的是将长期运行的修复操作记入专门的线程，因为用户可能取消其请求或希望取消与一应用程序关联的线程，而该修复操作确实需要运行来完成。

在某个未来的版本中，将用允许并发修复的意向来设计处理修复工作队列和工作项的例程。

损坏的类型及关联的修每文件属性

属性丢失。

属性列表损坏。

属性偏移超界。

属性记录长度＝＝0。

属性表损坏？？

属性VCN为负。

属性-＞RecordLength＝＝0。

AttributeList被损坏。

损坏的属性：坏的VCN范围、要查找VCN超出范围。

损坏的文件名属性、文件名链接坏、或目录丢失$INDEX-ROOT。

FILE-ATTRIBUTE-REPARSE-POINT标志未置位。

文件名属性丢失。

索引的属性已存在。

IndexEntry无效(损坏的属性)。

MFT数据属性丢失。

在打开的属性表中丢失条目。

非索引的属性已经存在。

非常驻$DATA属性丢失。

非常驻属性已存在。

常驻属性数据超过记录长度。

$STANDARD-INFORMATION属性丢失。

分配

对文件记录没有足够的分配空间。

分配损坏。

不能找到分配。

VCN坏。

VCN太大。

零VCN。

尝试访问超出分配的数据。

尝试设置LCN 0为空。

LCN在使用中。

非常驻AllocatedLength太大。

索引

损坏的索引树。

不能找到索引条目。空索引。

空索引条目叶。

索引缓冲区损坏。

索引条目已存在。

索引条目不存在。

索引条目损坏。

名字索引无效。

记录索引太大。

在重新分析点索引中未找到记录。

零长度的索引条目长度。

UpCase(大写)表

大写表太大。

不能访问大写表。

日志文件

无效的日志记录。日志文件满。

重起

无效的重起索引。

无效的重起表。

未分配的重起表条目。

安全性

损坏的安全性id。

文件损坏

文件记录损坏。

文件签名损坏。

文件大小大于分配值。

文件大小对重新分析点太大。

坏的文件记录？

无效的FileSize、ValidDataLength、或AllocationSize。

非常驻FileSize对重新分析点太大。

带未分配的范围的非分析文件。

RecordOffset超过FRS大小。

若存在0个或大于8个Vcn改变字节、大于8个Lcn改变字节，或若我们步查越过记录的末端，或Vcn改变是负的，则文件损坏。

MCB不存在。

MCB损坏。

预料外的文件引用。

失败的退出

步查互斥的FCB列表(和位图标志)以确定什么需要修复。

结论

虽然以对结构特征和/或方法动作专用的语言描述了本发明，然而可以理解，在附后权利要求中确定的本发明不必限于描述的具体的特征或动作。相反，具体特征和动作作为实现要求保护的本发明的示例形式来描述。

Claims (21)

1.一种用于实时文件系统修复的方法，其特征在于，包括：

检测对与文件系统请求相关联的存储卷上的数据的损坏；以及

实时修复所述损坏，使得在修复期间所述存储卷保持在线及活动，所述修复包括：

基于所述损坏挂起文件系统请求的执行；

确定和检测到的所述损坏相对应的修复扫描；

实现所述修复扫描；以及

当所述修复扫描完成时，重新开始所述文件系统请求的执行。

2.如权利要求1所述的方法，其特征在于，所述基于所述损坏挂起文件系统请求的执行包括：

在检测时记录描述所述损坏的信息，所述修复扫描是基于所述信息确定的；以及

产生表示所述损坏的错误状态，所述错误状态启动所述挂起。

3.如权利要求1所述的方法，其特征在于，所述检测对与文件系统请求相关联的存储卷上的数据的损坏包括在执行所述文件系统请求期间检测所述损坏。

4.如权利要求1所述的方法，其特征在于，所述检测对与文件系统请求相关联的存储卷上的数据的损坏包括在执行先前的文件系统请求期间检测所述损坏。

5.如权利要求1所述的方法，其特征在于，所述确定和检测到的所述损坏相对应的修复扫描包括确定包括较低层扫描的集合的复杂修复扫描。

6.如权利要求5所述的方法，其特征在于，所述实现所述修复扫描包括实现所述复杂修复扫描。

7.如权利要求6所述的方法，其特征在于，所述实现所述复杂修复扫描包括实现所述较低层扫描的集合。

8.如权利要求1所述的方法，其特征在于，所述实现所述修复扫描包括在当前线程中执行的顶层点运行修复例程。

9.如权利要求1所述的方法，其特征在于，所述实现所述修复扫描包括启动专门线程来服务所述修复扫描。

10.如权利要求1所述的方法，其特征在于，重新开始所述文件系统请求的执行包括完成所述文件系统请求。

11.如权利要求1所述的方法，其特征在于，所述修复扫描是非一般的修复扫描，且重新开始所述文件系统请求的执行包括：

使所述文件系统请求失败；以及

发出一损坏状态错误。

12.如权利要求1所述的方法，其特征在于，所述修复扫描与生成所述文件系统请求的应用程序的访问句柄不兼容，所述重新开始所述文件系统请求的执行包括：

使所述文件系统请求失败；以及

发出无效的句柄状态错误。

13.如权利要求1所述的方法，其特征在于，所述文件系统请求是递归请求，实现所述修复扫描包括：

展开到所述递归请求的顶层请求；以及

实现关于所述顶层请求的修复扫描。

14.如权利要求1所述的方法，其特征在于，所述修复扫描从包括下列的组中选出：

属性扫描；

文件扫描；

索引扫描；

卷位图重建；以及

安全性描述符文件扫描。

15.如权利要求1所述的方法，其特征在于，还包括：

接收与经受所述修复扫描的文件关联的第二文件系统请求；

若所述修复扫描是长期运行的修复，则使所述第二文件系统请求失败；以及

若所述修复扫描是短期运行的修复，则在所述修复扫描完成之前阻断所述第二文件系统请求。

16.如权利要求1所述的方法，其特征在于，还包括：

接收禁止所述修复扫描的文件系统控制命令；以及

若所述修复扫描是长期运行的修复，则禁止所述修复扫描。

17.如权利要求1所述的方法，其特征在于，还包括：

在实现所述修复扫描时检测另外的损坏；以及

将所述修复扫描推迟到新修复扫描完成之后。

18.如权利要求1所述的方法，其特征在于，还包括：

在实现所述修复扫描时检测间歇性硬件错误；

由于所述间歇性硬件错误而使所述修复扫描失败；以及

将所述失败的修复扫描记入事件日志。

19.如权利要求1所述的方法，其特征在于，还包括在所述修复扫描期间启动文件系统元数据上的确认扫描。

20.如权利要求19所述的方法，其特征在于，所述在所述修复扫描期间启动文件系统元数据上的确认扫描包括启动从包括下列的组中选出的确认扫描：

全卷扫描；

安全性扫描；

文件扫描；

流扫描；

目录扫描；以及

视图索引扫描。

21.一种用于实时文件系统修复的计算机，包括：

用于检测对与文件系统请求相关联的存储卷上的数据的损坏的装置；以及

用于实时修复所述损坏，使得在修复期间所述存储卷保持在线及活动的装置，所述用于实时修复所述损坏的装置包括：

基于所述损坏挂起文件系统请求的执行的装置；

确定和检测到的所述损坏相对应的修复扫描的装置；

实现所述修复扫描的装置；以及

当所述修复扫描完成时，重新开始所述文件系统请求的执行的装置。

Images