面向硬件故障的系统关键文件故障纠正方法及装置

摘要

本发明公开了一种面向硬件故障的系统关键文件故障纠正方法及装置，方法步骤如下：1）建立包含系统关键文件信息的备份文件表，为备份文件表的每一个目标文件建立副本文件并保持同步；2）实时检测操作系统文件操作故障并诊断故障原因，当发生操作故障的文件为备份文件表对应的目标文件且故障是由存储系统的硬件故障引起时执行下一步；3）使用对应的副本文件替代发生操作故障的文件并重试文件操作；装置包括副本文件管理模块、故障检测模块、故障诊断模块和故障处理模块。本发明能够防止由于文件访问失败而导致的系统宕机或者服务崩溃的问题，具有容错特性好、健壮性高、故障恢复实时、对用户透明、可扩展性强、通用性好的优点。

权利要求

1.一种面向硬件故障的系统关键文件故障纠正方法，其特征在于其实施步骤包括：

1）建立包含系统关键文件信息的备份文件表，为所述备份文件表对应的每一个目标文件在存储系统中建立副本文件，并将副本文件和对应的目标文件保持同步；

2）实时检测操作系统的文件操作故障并诊断故障原因，当发生文件操作故障的文件为所述备份文件表对应的目标文件且所述故障是由存储系统的硬件故障引起时执行下一步；

3）修改发生操作故障的文件的索引，使用对应的副本文件替代所述发生文件操作故障的文件，并调用文件系统的重试机制进行重试文件操作；

所述步骤2）的详细包括：

2.1）监测操作系统中文件的软件删除行为并检测操作系统的文件操作故障，在检测到文件操作故障时跳转执行下一步；

2.2）判断发生操作故障的文件是否为备份文件表对应的目标文件，如果不是备份文件表对应的目标文件则直接退出；如果是备份文件表对应的目标文件，则检查发生操作故障的文件是否存在软件删除行为，如果存在软件删除行为则在所述备份文件表中删除发生操作故障的文件对应的记录并退出，如果不存在软件删除行为则跳转执行下一步；

2.3）检测发生文件操作故障的文件是否存在，如果所述发生文件操作故障的文件不存在，则判定所述故障是由存储系统的硬件故障引起的并执行步骤3）。

2.根据权利要求1所述的面向硬件故障的系统关键文件故障纠正方法，其特征在于：所述步骤1）中建立的备份文件表还包括用户指定文件的文件信息。

3.根据权利要求2所述的面向硬件故障的系统关键文件故障纠正方法，其特征在于：所述步骤1）中建立副本文件具体是指将目标文件在不同的物理存储器或者同一物理存储器的不同区域中建立目标文件的副本文件。

4.根据权利要求3所述的面向硬件故障的系统关键文件故障纠正方法，其特征在于：所述步骤1）中将副本文件和对应的目标文件保持同步具体是指实时监测所述备份文件表中的每一个目标文件的文件变动操作，并根据监测结果对所述目标文件对应的副本文件进行相同的文件变动操作。

5.根据权利要求4所述的面向硬件故障的系统关键文件故障纠正方法，其特征在于，所述步骤1）还包括如下步骤：实时监测存储设备驱动程序上报的故障信息，如果检测到存储设备驱动程序上报的故障信息，则逐一读取所述备份文件表对应的每一个目标文件。

6.根据权利要求5所述的面向硬件故障的系统关键文件故障纠正方法，其特征在于，所述步骤3）的详细步骤包括：

3.1）预先设置用于限制重试文件操作次数的重试阈值、初始化用于对重试文件操作的次数进行计数的计数器；

3.2）进行重试文件操作前读取计数器的计数值，首先将计数器的计数值与重试阈值进行比较，如果计数器的计数值未超过重试阈值，则将计数器的计数值加1并跳转执行步骤

3.3）；如果计数器的计数值超过重试阈值，则退出重试文件操作；

3.3）修改发生文件操作故障的文件的索引，调用文件系统的重试机制进行重试文件操作，等待并获取重试文件操作结果，如果重试文件操作结果为成功则退出重试文件操作，如果重试文件操作结果为失败则继续返回执行步骤3.2）。

7.根据权利要求6所述的面向硬件故障的系统关键文件故障纠正方法，其特征在于：所述步骤3.3）还包括将发生文件操作故障的故障原因和重试文件操作的结果记录至日志文件的步骤。

8.一种面向硬件故障的系统关键文件故障纠正装置，其特征在于，包括：副本文件管理模块（1），用于建立包含系统关键文件信息的备份文件表、为所述备份文件表对应的每一个目标文件在存储系统中建立副本文件，并将副本文件和对应的目标文件保持同步；

故障检测模块（2），用于实时检测操作系统的文件操作故障；

故障诊断模块（3），用于诊断故障检测模块（2）检测到文件操作故障的故障原因，并当发生文件操作故障的文件为所述备份文件表对应的目标文件且所述故障是由存储系统的硬件故障引起时向故障处理模块（4）输出控制命令；

故障处理模块（4），用于根据故障诊断模块（3）输出的控制命令修改发生操作故障的文件的索引、使用对应的副本文件替代所述发生文件操作故障的文件，并调用文件系统的重试机制进行重试文件操作；

所述故障检测模块（2）包括：

第一部件，用于监测操作系统中文件的软件删除行为并检测操作系统的文件操作故障，在检测到文件操作故障时跳转执行第二部件；

第二部件，用于判断发生操作故障的文件是否为备份文件表对应的目标文件，如果不是备份文件表对应的目标文件则直接退出；如果是备份文件表对应的目标文件，则检查发生操作故障的文件是否存在软件删除行为，如果存在软件删除行为则在所述备份文件表中删除发生操作故障的文件对应的记录并退出，如果不存在软件删除行为则跳转执行第三部件；

第三部件，用于检测发生文件操作故障的文件是否存在，如果所述发生文件操作故障的文件不存在，则判定所述故障是由存储系统的硬件故障引起的并执行故障诊断模块（3）。

说明书

面向硬件故障的系统关键文件故障纠正方法及装置

技术领域

[0001] 本发明涉及高可靠计算机系统领域，具体涉及一种用于高端服务器中的面向硬件故障的系统关键文件实时动态纠正方法。

背景技术

[0002] 随着存储设备容量的不断攀升，存储设备发生故障的概率越来越高，这对计算机用户，特别是高端服务器用户来说是一个巨大的挑战。为了应对存储设备的越来高的故障率，硬件厂商包括一些系统软件提供商对此都提供了很多措施，如：构建磁盘冗余阵列等，但不管怎么说，不管采取什么措施，都避免不了存储设备故障的发生。

[0003] 存储设备发生故障对上层系统软件和应用软件来说影响是巨大的，例如：当存储设备发生故障，导致操作系统关键文件不能够访问时，就会导致系统崩溃、数据丢失，这是谁都不愿意看到的，特别是对于大型服务器来说，系统的宕机将导致巨大的损失；当存储设备发生故障，导致应用程序关键文件损坏、不能访问时，就可能导致该应用程序错误退出，如果该应用程序正在对外提供重要服务，就会导致服务中断，对用户造成不良影响，对服务提供者造成重大损失。

发明内容

[0004] 本发明要解决的技术问题是提供一种能够防止由于文件访问失败而导致系统宕机或者服务崩溃的问题，容错特性好、健壮性高、故障恢复实时、对用户透明、可扩展性强、通用性好的面向硬件故障的系统关键文件实时动态纠正方法。

[0005] 为了解决上述技术问题，本发明采用的技术方案为：

[0006] 一种面向硬件故障的系统关键文件故障纠正方法，其实施步骤包括：

[0007] 1）建立包含系统关键文件信息的备份文件表，为所述备份文件表对应的每一个目标文件在存储系统中建立副本文件，并将副本文件和对应的目标文件保持同步；

[0008] 2）实时检测操作系统的文件操作故障并诊断故障原因，当发生文件操作故障的文件为所述备份文件表对应的目标文件且所述故障是由存储系统的硬件故障引起时执行下一步；

[0009] 3）修改发生操作故障的文件的索引，使用对应的副本文件替代所述发生文件操作故障的文件，并调用文件系统的重试机制进行重试文件操作；

[0010] 所述步骤2）的详细步骤包括：

[0011] 2.1）监测操作系统中文件的软件删除行为并检测操作系统的文件操作故障，在检测到文件操作故障时跳转执行下一步；

[0012] 2.2）判断发生操作故障的文件是否为备份文件表对应的目标文件，如果不是备份文件表对应的目标文件则直接退出；如果是备份文件表对应的目标文件，则检查发生操作故障的文件是否存在软件删除行为，如果存在软件删除行为则在所述备份文件表中删除发生操作故障的文件对应的记录并退出，如果不存在软件删除行为则跳转执行下一步；

[0013] 2.3）检测发生文件操作故障的文件是否存在，如果所述发生文件操作故障的文件不存在，则判定所述故障是由存储系统的硬件故障引起的并执行步骤3）。

[0014] 作为本发明面向硬件故障的系统关键文件故障纠正方法的进一步改进：

[0015] 所述步骤1）中建立的备份文件表还包括用户指定文件的文件信息。

[0016] 所述步骤1）中建立副本文件具体是指将目标文件在不同的物理存储器或者同一物理存储器的不同区域中建立目标文件的副本文件。

[0017] 所述步骤1）中将副本文件和对应的目标文件保持同步具体是指实时监测所述备份文件表中的每一个目标文件的文件变动操作，并根据监测结果对所述目标文件对应的副本文件进行相同的文件变动操作。

[0018] 所述步骤1）还包括如下步骤：实时监测存储设备驱动程序上报的故障信息，如果检测到存储设备驱动程序上报的故障信息，则逐一读取所述备份文件表对应的每一个目标文件。

[0019] 所述步骤3）的详细步骤包括：

[0020] 3.1）预先设置用于限制重试文件操作次数的重试阈值、初始化用于对重试文件操作的次数进行计数的计数器；

[0021] 3.2）进行重试文件操作前读取计数器的计数值，首先将计数器的计数值与重试阈值进行比较，如果计数器的计数值未超过重试阈值，则将计数器的计数值加1并跳转执行步骤3.3）；如果计数器的计数值超过重试阈值，则退出重试文件操作；

[0022] 3.3）修改发生文件操作故障的文件的索引，调用文件系统的重试机制进行重试文件操作，等待并获取重试文件操作结果，如果重试文件操作结果为成功则退出重试文件操作，如果重试文件操作结果为失败则继续返回执行步骤3.2）。

[0023] 所述步骤3.3）还包括将发生文件操作故障的故障原因和重试文件操作的结果记录至日志文件的步骤。

[0024] 本发明还提供一种面向硬件故障的系统关键文件故障纠正装置，包括[0025] 副本文件管理模块，用于建立包含系统关键文件信息的备份文件表、为所述备份文件表对应的每一个目标文件在存储系统中建立副本文件，并将副本文件和对应的目标文件保持同步；

[0026] 故障检测模块，用于实时检测操作系统的文件操作故障；

[0027] 故障诊断模块，用于诊断故障检测模块检测到文件操作故障的故障原因，并当发生文件操作故障的文件为所述备份文件表对应的目标文件且所述故障是由存储系统的硬件故障引起时向故障处理模块输出控制命令；

[0028] 故障处理模块，用于根据故障诊断模块输出的控制命令修改发生操作故障的文件的索引、使用对应的副本文件替代所述发生文件操作故障的文件，并调用文件系统的重试机制进行重试文件操作；

[0029] 所述故障检测模块包括：

[0030] 第一部件，用于监测操作系统中文件的软件删除行为并检测操作系统的文件操作故障，在检测到文件操作故障时跳转执行第二部件；

[0031] 第二部件，用于判断发生操作故障的文件是否为备份文件表对应的目标文件，如果不是备份文件表对应的目标文件则直接退出；如果是备份文件表对应的目标文件，则检查发生操作故障的文件是否存在软件删除行为，如果存在软件删除行为则在所述备份文件表中删除发生操作故障的文件对应的记录并退出，如果不存在软件删除行为则跳转执行第三部件；

[0032] 第三部件，用于检测发生文件操作故障的文件是否存在，如果所述发生文件操作故障的文件不存在，则判定所述故障是由存储系统的硬件故障引起的并执行故障诊断模块。

[0033] 本发明面向硬件故障的系统关键文件故障纠正方法具有下述优点：

[0034] 1、本发明基于文件多副本的思想，针对硬件故障采用文件实时动态备份、通过检测文件操作故障、诊断故障原因来实现对文件操作故障进行分析，将由于系统硬件发生故障而导致文件操作故障的目标文件的索引指向对应副本文件进行重试文件操作方法，目的不在于防止存储设备发生故障，而是用于防止当系统存储设备发生硬件故障时，可以更好的保护整个系统正常运行，将硬件故障造成的影响降到最低，能够有效的避免因系统硬件故障导致的文件无法访问、防止因系统关键文件不能够访问导致的系统宕机或服务崩溃现象，使系统的健壮性得到了十分明显的提高，具有容错特性好、健壮性高、故障恢复实时、对用户透明、可扩展性强、通用性好的优点。

[0035] 2、本发明虽然只针对硬件故障、只针对特定的文件，但是对非硬件故障也能够提供操作接口，系统关键文件是通过备份文件表由用户来指定的，在集群系统中可以同时部署，相互之间不会相互影响，具有可扩展性强的优点。

[0036] 3、本发明的文件操作故障管理框架本身并不依赖于特定的平台，任何支持文件系统的操作系统都可以采用本发明进行实时动态的文件操作故障修复，支持平台的多样性，具有通用性好的优点。

[0037] 本发明面向硬件故障的系统关键文件故障纠正装置为本发明具有面向硬件故障的系统关键文件故障纠正方法相对应的结构，因此也应当具有与面向硬件故障的系统关键文件故障纠正方法相同的技术效果，在此不再赘述。

附图说明

[0038] 图1为本发明实施例的基本流程示意图。

[0039] 图2为本发明实施例的框架结构示意图。

[0040] 图3为本发明实施例的副本文件管理模块和故障处理模块的工作流程示意图。

[0041] 图4为本发明实施例的故障检测模块和故障诊断模块的工作流程示意图。

[0042] 图5为本发明实施例的目标文件不存在的诊断及处理流程示意图。

[0043] 图6为本发明实施例的目标文件存在的诊断及处理流程示意图。

[0044] 图7为本发明实施例的目标文件和备份文件存位于不同磁盘的处理数据流程示意图。

[0045] 图例说明：1、副本文件管理模块；2、故障检测模块；3、故障诊断模块；4、故障处理模块。

具体实施方式

[0046] 如图1所示，本实施例面向硬件故障的系统关键文件故障纠正方法的实施步骤如下：

[0047] 1）建立包含系统关键文件信息的备份文件表，为备份文件表对应的每一个目标文件在存储系统中建立副本文件，并将副本文件和对应的目标文件保持同步；

[0048] 2）实时检测操作系统的文件操作故障并诊断故障原因，当发生文件操作故障的文件为备份文件表对应的目标文件且故障是由存储系统的硬件故障引起时执行下一步；

[0049] 3）修改发生操作故障的文件的索引，使用对应的副本文件替代发生文件操作故障的文件，并调用文件系统的重试机制进行重试文件操作。

[0050] 当一个系统进程去访问自己必须的文件时，如果该文件因硬件故障导致文件无法访问，此时就会导致该系统进程异常结束，如果该系统进程为系统关键进程，则可导致系统死机，这是一个很严重的问题。而本实施例通过再次尝试的方法来访问副本文件，就能够避免因为文件操作故障导致进程退出或系统死机，健壮性大大提高，能够更好的保护整个系统正常运行，解决因硬件故障导致的操作系统宕机、服务崩溃、应用程序无法继续执行问题，将硬件故障造成的影响降到最低，具有容错特性好、健壮性高、故障恢复实时、对用户透明、可扩展性强、通用性好的优点。

[0051] 本实施例步骤1）中建立的备份文件表还包括用户指定文件的文件信息，能够根据用户定义来扩展本实施例的功能，不仅可以用于实现对操作系统关键文件的保护，而且还可以扩展对其他文件进行保护；此外也可以仅根据系统关键文件的文件信息建立备份文件表。本实施例的备份文件表为基于用户定义的，因此也能够实现监控所有文件，但是监控的文件操作对象是有限的，随着系统的持续运行和数据文件的不断增加，会导致文件的数目迅速增大，对所有的文件采用此种方式的监控和处理是很不合算的，考虑到系统性能及磁盘利用率的问题，本实施例中只针对影响系统正常运行的系统关键文件，和用户自定义的用户指定文件，从而能够在系统性能、磁盘利用率和可靠性之间获得较佳的平衡，能够保证系统关键文件以及用户指定文件的高可靠性访问：当系统对文件进行操作时，如果因硬件故障导致文件操作失败现象，并且该问题能够通过本方法进行修复，那么本方法就能够保证，系统不会发生因对系统关键文件及用户指定文件访问失败而导致的系统崩溃现象。本实施例作为一种在系统因硬件故障而导致的文件操作失败时的解决方案，通过检测文件系统操作失败的原因来进行相应的处理，如果是硬件故障导致的文件操作失败，那么就采用该文件的其它副本来进行替代访问，并且该访问对用户来说是透明的，系统会自动将文件索引指向副本文件，通过采用实时备份的方法，通过更改文件索引，能够有效解决因硬件故障导致的文件操作失败问题，进而有效防止因文件访问失败而导致的系统死机崩溃问题，具有故障实时恢复的优点，文件操作故障的修复是实时进行的，在能修复的故障情形下，对用户来说和正常的操作没有两样，只是有时会出现轻微延迟的现象，并不影响正常的操作，因此具有对用户透明的优点。

[0052] 步骤1）中建立副本文件具体是指将目标文件在不同的物理存储器或者同一物理存储器的不同区域（例如分区）中建立目标文件的副本文件，通过将目标文件和副本文件分存储区域进行分开存储，因此只要有一个存储区域内的文件是可以正常访问的，那么该文件就能够被正常访问，从而保证目标文件和对应的副本文件之间相对独立性，可靠性高、健壮性好。一般而言，存储系统的硬件故障导致文件操作故障包括两种形式：第一种形式是物理存储器硬件（如SCSI盘）已完全损坏，无法进行任何操作；第二种形式只针对物理设备本身出现部分不能访问的情形。例如物理存储器硬件部分损坏，SCSI盘出现坏块、坏道，而其他部分是好的。因此针对第一种形式，如果目标文件和对应的副本文件分别存储在两个不同的物理存储器，如果目标文件所在的物理存储器发生损坏，则能够通过分布于不同物理存储器的副本文件代替目标文件进行文件操作；针对第二种形式，如果目标文件和对应的副本文件分别存储在同一物理存储器的两个不同的区域，如果目标文件所在的区域发生损坏也可以通过分布于同一物理存储器另一区域的副本文件代替目标文件进行文件操作，这两种形式的特征在于备份文件和源文件是在不同的物理存储区域里面的。

[0053] 步骤1）中将副本文件和对应的目标文件保持同步具体是指实时监测备份文件表中的每一个目标文件的文件变动操作，并根据监测结果对目标文件对应的副本文件进行相同的文件变动操作，副本文件和目标文件之间是实时进行同步的，对源文件的任何操作都会实时的反映到副本文件之上，而且对存储系统的消耗较小、对系统性能的影响较小。此外，也可以直接采用复制的方式建立副本文件，但是相对磁盘读写操作将多，系统性能相对较差。

[0054] 步骤1）还包括如下步骤：实时监测存储设备驱动程序上报的故障信息，如果检测到存储设备驱动程序上报的故障信息，则逐一读取备份文件表对应的每一个目标文件。因此能够有效根据存储设备驱动程序上报的故障信息来主动触发对备份文件表对应的每一个目标文件进行文件操作，能够快速及时对备份文件表对应的目标文件进行处理，检测更加快速及时。此外，也可以不监测存储设备驱动程序上报的故障信息，而通过操作系统的正常文件操作时的文件操作故障来判断发生文件操作故障，但是这样由于一些系统关键文件或者用户定义文件可能需要很长的时间才会进行文件操作，因此导致检测处理周期过长。

[0055] 本实施例中，步骤2）的详细步骤如下：

[0056] 2.1）监测操作系统中文件的软件删除行为并检测操作系统的文件操作故障，在检测到文件操作故障时跳转执行下一步；

[0057] 2.2）判断发生操作故障的文件是否为备份文件表对应的目标文件，如果不是备份文件表对应的目标文件则直接退出；如果是备份文件表对应的目标文件，则检查发生操作故障的文件是否存在软件删除行为，如果存在软件删除行为则在备份文件表中删除发生操作故障的文件对应的记录并退出，如果不存在软件删除行为则跳转执行下一步；

[0058] 2.3）检测发生文件操作故障的文件是否存在，如果发生文件操作故障的文件不存在，则判定故障是由存储系统的硬件故障引起的并执行下一步（步骤3）。

[0059] 本实施例中，步骤3）的详细步骤包括：

[0060] 3.1）预先设置用于限制重试文件操作次数的重试阈值、初始化用于对重试文件操作的次数进行计数的计数器；

[0061] 3.2）进行重试文件操作前读取计数器的计数值，首先将计数器的计数值与重试阈值进行比较，如果计数器的计数值未超过重试阈值，则将计数器的计数值加1并跳转执行步骤3.3）；如果计数器的计数值超过重试阈值，则退出重试文件操作；

[0062] 3.3）修改发生文件操作故障的文件的索引，调用文件系统的重试机制进行重试文件操作，等待并获取重试文件操作结果，如果重试文件操作结果为成功则退出重试文件操作，如果重试文件操作结果为失败则继续返回执行步骤3.2）。

[0063] 本实施例中，步骤3.3）还包括将发生文件操作故障的故障原因和重试文件操作的结果记录至日志文件的步骤，以便用户进行后期的检查以及维护。在调用文件系统的重试机制进行重试文件操作后，文件系统的重试机制会返回重试文件操作的执行结果，如果执行成功则返回系统的正常操作，如果执行仍然失败则返回故障原因；本实施例中只要文件操作故障是由硬件故障引起的，那么不管恢复操作的结果如何都会保存产生故障的相关信息以及故障修复后的结果，这些结果会保存到一个专门的日志文件之中。

[0064] 如图2所示，本实施例面向硬件故障的系统关键文件故障纠正装置包括：

[0065] 副本文件管理模块1，用于建立包含系统关键文件信息的备份文件表、为备份文件表对应的每一个目标文件在存储系统中建立副本文件，并将副本文件和对应的目标文件保持同步；

[0066] 故障检测模块2，用于实时检测操作系统的文件操作故障；

[0067] 故障诊断模块3，用于诊断故障检测模块2检测到文件操作故障的故障原因，并当发生文件操作故障的文件为备份文件表对应的目标文件且故障是由存储系统的硬件故障引起时向故障处理模块4输出控制命令；

[0068] 故障处理模块4，用于根据故障诊断模块3输出的控制命令修改发生操作故障的文件的索引、使用对应的副本文件替代发生文件操作故障的文件，并调用文件系统的重试机制进行重试文件操作。

[0069] 本实施例中，副本文件管理模块1用于建立副本文件并负责维持副本文件同步，该模块还提供实施文件索引修改控制的操作接口，故障处理模块4调用副本文件管理模块1的实施文件索引修改控制的操作接口将副本文件替代发生操作故障的文件；故障检测模块2用于检测故障，该模块还提供监视由存储设备驱动上报的故障信息；故障诊断模块3用于诊断故障；故障处理模块4用于发送修改文件索引操作命令和将故障原因和重试文件操作的结果记录至日志文件。

[0070] 如图3所示，本实施例中副本文件管理模块1的工作步骤如下：

[0071] 获取副本文件存放位置，本实施例的副本文件和目标文件分别放置于不同的物理存储器上；创建默认文件备份；创建用户指定文件备份；监视文件变动情况（如：修改、删除、文件属性更改等）；根据监视结果对副本文件进行同样操作。

[0072] 副本文件管理模块1建立副本文件并负责维持副本文件和原文件的同步，该模块还提供实施文件索引修改控制的操作接口，当接收到故障处理模块4的操作请求时，就会将相应的文件索引更改至副本文件，它完成以下操作：首先会强制删除失效的文件，然后建立一个指向副本文件的链接，从而完成从源文件到副本文件的访问的过渡。

[0073] 本实施例中故障处理模块4的工作步骤如下：等待文件访问硬件故障事件；获取故障文件名称；清理原始文件现场；更改故障文件的索引使用副本文件替代故障文件；将副本文件链接到原文件所在目录；返回处理结果并将故障原因和重试文件操作的结果记录至日志文件。

[0074] 故障检测模块2能够检测到文件访问失败问题，并且能够将相应的故障信息传递给故障诊断模块3进行诊断，同时故障检测模块2通过监测存储设备驱动程序上报的故障信息，来时刻监视存储设备硬件故障的发生，如果存储设备发生硬件故障，就会去判断在该存储区域内是否存在备份文件表对应的目标文件，如果存在备份文件表对应的目标文件，那么就直接将该信息传递给故障诊断模块3，故障诊断模块3只进行简单的判断就可将更改文件索引操作需求提交给故障处理模块4，然后故障处理模块4进行后续的处理。故障诊断模块3根据故障检测模块2提供的信息，结合已定义的相关问题列表对文件访问失败的原因进行诊断，最后给出诊断结果，故障处理模块4则根据故障诊断模块3提供的诊断结果进行操作，如果诊断结果显示是由硬件故障导致的文件操作错误，则故障处理模块4就会判断目标文件是否存在副本，如果存在副本，就将更改原始文件索引指向副本文件的命令发送给副本文件管理模块1，该模块负责完成文件索引更改工作，然后故障处理模块4调用文件系统的重试机制进行重试文件操作。本实施例中，用于限制重试文件操作次数的重试阈值取值为3，如果副本文件也不能够正常访问，在重试3次之后就交给系统处理。

[0075] 如图4所示，本实施例中故障检测模块2的工作步骤如下：获取监视文件信息；监视文件读写操作情况；判断文件访问是否出错；在文件访问出错时报告文件操作出错信息，否则返回继续监视文件读写操作情况。本实施例中故障诊断模块3的工作步骤如下：
监测存储设备驱动上报故障信息；判断是否为硬件故障，如果不是硬件故障则返回继续监测存储设备驱动上报故障信息，否则继续下一步；判断故障区域是否存在关键文件（备份文件表对应的目标文件），如果存在关键文件则报告区域文件硬件故障信息；如果不存在关键文件则记录存储设备故障信息。故障诊断模块3在进行读目标文件时预先判断文件是否存在，并针对判断结果分别进行不同的处理。

[0076] 如图5所示，如果文件不存在，故障诊断模块3则直接进行诊断文件不存在的原因。文件不存在既可能是软件原因引起的，也可能是硬件故障硬件引起的。软件原因引起的是指系统在运行期间发现该文件已经没有使用价值，此时会采取删除操作将其删除，或者是管理员人为的将该文件删除；硬件故障引起的包括存储设备出现坏块、坏道等情况，或者是整个存储设备本身故障，不可访问，此时都会引起访问文件不存在的现象。故障的检测在不同操作系统及对应硬件平台下有所不同，就linux系统而言，主要是通过在相应驱动程序中增强故障输出信息，从而实时获取存储设备的健康状态，这个过程可分为以下几个步骤来完成，首先通过内核里的故障消息接收线程获取由驱动程序上报的故障信息，然后通过消息处理线程对故障消息进行名值对化、格式化，接着打包通过消息发送线程发送给（netlink机制）核外处理程序进行处理。故障的诊断相对来说处理逻辑比较简单，首先判断不存在的文件是否在关键文件备份表里面，如果不存在就不做进一步处理，当然对于那些因软件原因而删除的关键文件，在linux系统下会同过inotify机制进行监控，如果是软件行为的删除，那么就将关键文件备份表了面的对应项删除，此后对该文件的访问导致的文件不存在，将不做处理，只提供备份文件和访问失败信息记录，由管理员在需求的时候从备份区域进行复制，如果不存在的文件在关键文件备份表里面，那么就可判断不存在的原因是由其他原因引起的，通常情况下就是因硬件故障引起的，如果说是因为连接存储设备的连线导致的文件不可访问，那么也认为是存储设备自身的问题导致的故障，不影响故障的处理，当然也可以对这些故障类型进行分类。故障的处理处理逻辑也比较简单，当故障诊断模块3将要处理的故障文件信息发送给自己的时候，主要进行两个操作，一是将需要更改文件索引的命令发送给副本文件管理模块1进行处理，二是记录相关的故障详细信息及故障处理结果。

[0077] 如图6所示，如果发生文件操作故障的文件存在，故障诊断模块3则首先进行文件读操作，然后根据操作的结果进行诊断文件不存在的原因。这种情况通常是由于文件分配表中的内容正常，而文件数据区的内容正好落到了如磁盘的坏块或者坏道中所导致的，该处理流程和因硬件故障导致文件不存在时的处理流程相似，也包括故障的检测，故障诊断和故障处理几个过程，但此时故障诊断的过程相对来说比较复杂一定，此时在我们看来文件是存在的，但在访问时回报如无效的文件尾等信息，由于我们一直对关键文件进行监视，它们权限的变更、内容的更改都实时的进行了记录，一种方法是在linux下用inotify机制对关键文件进行监控，并对关键文件的更改进行实时的监控，当判断文件本身可以正常访问，但是却无法正常访问的时候，就认为此时发生了硬件故障，导致文件不能够正常访问，当然也有可能是文件在存储的过程中出现了问题，而不是硬件故障本身所引进的，这种情况下也把该情形视为硬件故障的一种，从而进行后续的故障处理，保证整个系统不间断的运行。

[0078] 从本实施例中可以看出，发生文件操作故障的原因是由于硬件故障引起时，硬件故障包括两种类型，第一种类型是该硬件如SCSI盘已完全损坏，无法进行任何操作；第二种类型是该硬件部分损坏，如SCSI盘出现坏块、坏道，而其他部分是好的。文件操作故障的修复是实时进行的，在能修复的故障情形下，对用户来说和正常的操作没有两样，只是有时会出现轻微延迟的现象，并不影响正常的操作。如果文件操作故障是由硬件故障引起的，那么不管恢复操作的结果如何，都会保存产生故障的相关信息以及故障修复后的结果，这些结果会保存到一个专门的日志文件之中，以便用户进行后期的维护。虽然本实施例也能够监控所有文件，但是由于考虑到系统性能及磁盘利用率的问题，只针对影响系统正常运行的关键文件，和用户自定义的关键文件。监控的文件操作对象是有限的，随着系统的持续运行和数据文件的不断增加，会导致文件的数目迅速增大，对所有的文件采用此种方式的监控和处理是很不合算的，本方法的目的是在于保证系统关键文件的正常访问和用户自定义关键文件的正常访问。当系统对文件进行操作时，如果因硬件故障导致文件操作失败现象，并且该问题能够通过本方法进行修复，那么本实施例就能够保证，系统不会发生因对系统关键文件访问失败而导致的系统崩溃现象。

[0079] 如图7所示，本实施例中的目标文件（源文件）和备份文件分别存放在不同的磁盘（物理存储器）之中，当然副本文件（备份文件）和目标文件也可以存放在同一磁盘的不同分区，前提是在出现故障时副本文件可以正常访问，此时就对用户来说透明的进行操着，从而达到硬件故障下的系统关键文件实时动态纠正。备份文件是处于不同物理位置的，其组织形式包括两种形式，第一个形式是将文件存储在不同的物理硬件上，如两个不同的SCSI硬盘上，第二种形式是将文件存储在同一个物理设备上。第一种形式针对的是整个物理设备无法进行任何操作和物理设备本身出现部分不能访问的情形，第二种形式只针对物理设备本身出现部分不能访问的情形。这两种形式的特征在于，备份文件和源文件是在不同的物理存储区域里面的，只要有一个存储区域内的文件是可以正常访问的，那么该文件就能够被正常访问。源文件可以有多个副本，并且这多个副本是存放在不同的物理存储区域的，一种好的方式是将文件副本存储在多个不同的物理存储上，另外一种方式是将多个副本存储在单个物理存储设备的不同区域，如存放在一个物理硬盘的不同分区之中。副本文件的备份是实时进行的，对源文件的任何操作都会实时的反映到副本文件之上。

[0080] 以上所述仅是本发明的优选实施方式，本发明的保护范围并不仅局限于上述实施例，凡属于本发明思路下的技术方案均属于本发明的保护范围。应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理前提下的若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。