WO2017173927A1

WO2017173927A1 - 分布式存储系统硬盘挂住故障检测、处理方法及装置

Info

Publication number: WO2017173927A1
Application number: PCT/CN2017/077995
Authority: WO
Inventors: 王勇; 赵树起; 朱家稷; 董乘宇
Original assignee: 阿里巴巴集团控股有限公司
Priority date: 2016-04-07
Filing date: 2017-03-24
Publication date: 2017-10-12
Also published as: TW201737111A; CN107273231A

Abstract

一种分布式存储系统硬盘挂住故障检测、处理方法及装置，其通过检测目标硬盘对应的访问请求的执行时间来判断该目标硬盘是否出现挂住故障，可以及时发现目标硬盘的挂住故障；在发现目标硬盘出现挂住故障后，一方面通过状态标记避免故障硬盘再次被访问，另一方面清理故障硬盘占用的系统资源，使得其他进程可以重新分配应用这些系统资源，降低硬盘挂住故障可能带来的不利影响，达到止损目的。既不需要依赖硬盘厂商提供检测工具，也不需要在硬盘上增加新硬件，也不需要人为干预，简单易行，不会影响硬盘的生产及使用成本。

Description

分布式存储系统硬盘挂住故障检测、处理方法及装置

本申请要求2016年04月07日递交的申请号为201610212740.0、发明名称为“分布式存储系统硬盘挂住故障检测、处理方法及装置”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。

技术领域

本发明涉及计算机技术领域，尤其涉及一种分布式存储系统硬盘挂住故障检测、处理方法及装置。

背景技术

分布式存储系统是构建在本地文件系统之上的存储系统，其将数据分散存储到多个硬盘上。对于分布式存储系统而言，从本地文件系统到各个硬盘内部的整个链路上都有可能出现故障，其中硬盘挂住(hang up)故障，表现为硬盘无法响应正常的操作，所有对该硬盘的输入输出操作都因为整个链路没有应答而不能中止。挂住的硬盘如果处理不当可能会导致整个访问进程失去响应，进而导致使该进程所管理的数据都无法访问、前端请求延时变高、系统负载增加、数据可用性降低等问题。故及时检测到硬盘挂住故障，降低该故障造成的影响，是保证分布式存储系统性能的一个关键问题。

现有的硬盘挂住故障处理方法主要包括以下四种：(1)使用硬盘厂商提供的工具向硬盘发出下线指令，硬盘收到下线指令后停止工作，从而使对硬盘的访问能够返回，终止硬盘挂住状态；(2)使用硬盘的硬件开关停止硬盘工作，通常是在现有硬盘上增加一个部件，通过该部件直接拉低硬盘的电压，使硬盘掉电，从而终止硬盘挂住状态；(3)重启机器，重启后，硬盘状态被重置，但只存在改善硬盘挂住状态的可能性；(4)直接重启进程，新的进程会规避使用挂住的硬盘。

但是上述处理方法都存在一定的缺陷，包括需要依赖额外的辅助工具、影响系统资源可用性等。具体的，上述方法(1)需要依赖于硬盘厂商提供的工具，且不适用于硬盘无法接受下线指令的情况，实际应用成功率较低；方法(2)需要在硬盘上增加新硬件(即硬件开关)，导致硬盘开发和维护的成本增加，且适用范围窄；方法(3)引入了人为干预，在机器重启期间，机器本身和存储系统的可用性降低，而且存在重启失败的可能，即使重启成功，也需要存储系统能够规避对挂住的硬盘的使用，对存储系统的要求较高；方法(4)中原有进程因为有线程挂住，无法释放内存资源，使得系统内存占用高，即使重启了系统的可用资源也会降低。因此，亟需一种成功率高、适用范围广、对系统可用性影响小的硬盘挂住故障处理方法。

发明内容

本申请要解决的第一个技术问题是，在不依靠辅助工具的前提下实现分布式存储系统硬盘挂住故障的自动检测；为此，本申请提供一种分布式存储系统硬盘挂住故障检测方法及装置。

本申请第一方面，提供一种分布式存储系统硬盘挂住故障检测方法，包括：

检测目标硬盘对应的各个访问请求的执行时间；

判断是否存在执行时间大于对应的预设阈值的时滞请求；

如果存在所述时滞请求，则确定所述目标硬盘出现挂住故障。

结合第一方面，在本申请第一方面第一种可行的实施方式中，所述故障检测方法还包括：

创建所述目标硬盘对应的IO线程组；

通过所述IO线程组读取并处理所述目标硬盘对应的各个访问请求，以完成对所述目标硬盘的读写操作。

结合第一方面，或者第一方面第一种可行的实施方式，在第一方面第二种可行的实施方式中，检测目标硬盘对应的各个访问请求的执行时间，包括：

检测目标硬盘的输入队列中处于队头位置的访问请求的执行时间。

本申请第二方面，提供一种分布式存储系统硬盘挂住故障检测装置，包括：

检测单元，用于检测目标硬盘对应的各个访问请求的执行时间；

比较单元，用于判断是否存在执行时间大于对应的预设阈值的时滞请求，如果存在所述时滞请求，则确定所述目标硬盘出现挂住故障。

结合第二方面，在第二方面第一种可行的实施方式中，所述故障检测装置还包括：

进程管理单元，用于创建所述目标硬盘对应的IO线程组，并通过所述IO线程组读取并处理所述目标硬盘对应的各个访问请求，以完成对所述目标硬盘的读写操作。

结合第二方面，或者第二方面第一种可行的实施方式，在第二方面第二种可行的实施方式中，为实现检测目标硬盘对应的各个访问请求的执行时间，所述检测单元具体被配置为：

由以上技术方案可知，本申请实施例通过检测目标硬盘对应的访问请求的执行时间来判断该目标硬盘是否出现挂住故障，可以及时发现目标硬盘的挂住故障；且该挂住故障检测方式既不需要依赖硬盘厂商提供检测工具，也不需要在硬盘上增加新硬件，也不需要人为干预，简单易行，不会影响硬盘的生产及使用成本。

本申请要解决的第二个技术问题是，在不依靠辅助工具的前提下实现分布式存储系统硬盘挂住故障的自动处理；为此，本申请提供一种分布式存储系统硬盘挂住故障处理方法及装置。

本申请第三方面，提供一种分布式存储系统硬盘挂住故障处理方法，包括：

当目标硬盘出现挂住故障时，将所述目标硬盘的状态标记为挂住故障状态；

清理所述目标硬盘对应的被挂住管理进程所占用的系统资源，以便启动新的用于管理所述目标硬盘的管理进程。

结合第三方面，在第三方面第一种可行的实施方式中，清理所述目标硬盘对应的被挂住管理进程所占用的系统资源，包括：

申请新内存，并通过所述新内存执行下述两步操作，以清除所述被挂住管理进程占用的内存资源；

查找得到所述被挂住进程占用的全部内存段；

分别解除每个内存段对应的内存映射。

结合第三方面，或者第三方面第一种可行的实施方式，在第三方面第二种可行的实施方式中，所述故障处理方法还包括：

在清理所述目标硬盘对应的被挂住管理进程所占用的系统资源之前，弹出所述目标硬盘的输入队列中缓存的各个访问请求，并返回所述目标硬盘的故障信息。

结合第三方面，或者第三方面第一种可行的实施方式，在第三方面第三种可行的实施方式中，所述故障处理方法还包括：

在每次启动所述目标硬盘的管理进程后，确定所述目标硬盘的状态；

如果所述目标硬盘的状态为挂住故障状态，则禁止对所述目标硬盘的访问。

结合第三方面，或者第三方面第一种可行的实施方式，在第三方面第四种可行的实施方式中，所述故障处理方法还包括：

将所述目标硬盘的挂住故障状态保存至正常的硬盘。

本申请第四方面，提供一种分布式存储系统硬盘挂住故障处理装置，包括：

状态管理单元，用于当目标硬盘出现挂住故障时，将所述目标硬盘的状态标记为挂住故障状态；

资源清理单元，用于清理所述目标硬盘对应的被挂住管理进程所占用的系统资源，以便启动新的用于管理所述目标硬盘的管理进程。

结合第四方面，在第四方面第一种可行的实施方式中，为实现清理所述目标硬盘中被挂住管理进程所占用的系统资源，所述资源清理单元具体被配置为，申请新内存，并通过所述新内存执行下述两步操作，以清除所述被挂住管理进程占用的内存资源：查找得到所述被挂住进程占用的全部内存段，以及分别解除每个内存段对应的内存映射。

结合第四方面，或者第四方面第一种可行的实施方式，在第四方面第二种可行的实施方式中，所述故障处理装置还包括：

请求清理单元，用于弹出所述目标硬盘的输入队列中缓存的各个访问请求，并返回所述目标硬盘的故障信息。

结合第四方面，或者第四方面第一种可行的实施方式，在第四方面第三种可行的实施方式中，所述故障处理装置还包括：

可用性监督单元，用于在每次启动所述目标硬盘的管理进程后，确定所述目标硬盘的状态，并在所述目标硬盘的状态为挂住故障状态时，禁止对所述目标硬盘的访问。

结合第四方面，或者第四方面第一种可行的实施方式，在第四方面第四种可行的实施方式中，所述状态管理单元，还用于：将所述目标硬盘的挂住故障状态保存至正常的硬盘。

由以上技术方案可知，本申请实施例在发现目标硬盘出现挂住故障后，一方面通过状态标记避免故障硬盘再次被访问，另一方面清理故障硬盘占用的系统资源，使得其他进程可以重新分配应用这些系统资源，降低硬盘挂住故障可能带来的不利影响，达到止损目的。可见，本申请实施例提供的挂住故障处理方案既不需要依赖硬盘厂商提供检测工具，也不需要在硬盘上增加新硬件，也不需要人为干预，简单易行，不会影响硬盘的生产及使用成本。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本申请。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，对于本领域普通技术人员而言，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为本申请一示例性实施例示出的一种分布式存储系统硬盘挂住故障检测方法的流程图；

图2为本申请一示例性实施例示出的分布式存储系统中一个数据存储节点中访问请求处理流程示意图；

图3为本申请一示例性实施例示出的一种分布式存储系统硬盘挂住故障处理方法的流程图；

图4为本申请一示例性实施例示出的另一种分布式存储系统硬盘挂住故障处理方法的流程图；

图5为本申请一示例性实施例示出的分布式存储系统硬盘挂住故障检测及处理方法时序图；

图6为本申请一示例性实施例示出的一种分布式存储系统硬盘挂住故障检测装置的结构框图；

图7为本申请一示例性实施例示出的一种分布式存储系统硬盘挂住故障处理装置的结构框图；

图8为本申请一示例性实施例示出的另一种分布式存储系统硬盘挂住故障处理装置的结构框图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。

为了全面理解本申请，在以下详细描述中提到了众多具体的细节，但是本领域技术人员应该理解，本申请可以无需这些具体细节而实现。在其他实施例中，不详细描述公知的方法、过程、组件和电路，以免不必要地导致实施例模糊。

图1为本申请一示例性实施例示出的一种分布式存储系统硬盘挂住故障检测方法的流程示意图。如图1所示，所述检测方法包括：

S101、检测目标硬盘对应的各个访问请求的执行时间。

所述访问请求，具体可以包括从目标硬盘中读取数据的读请求(Output)，以及向目标硬盘中写入数据或修改数据的写请求(Input)等，有目标硬盘的管理进程统一调度并执行。

S102、判断是否存在执行时间大于对应的预设阈值的时滞请求。

S103、如果存在所述时滞请求，则确定所述目标硬盘出现挂住故障。

实际应用中，无论因何种原因(如硬件损坏、读写超负荷等)导致硬盘出现挂住故障，其直接表现都至少包括正在执行的对于该硬盘的访问请求在很长一段时间内都未执行结束。有鉴于此，本申请实施例通过检测目标硬盘对应的访问请求的执行时间来判断该目标硬盘是否出现挂住故障，可以及时发现目标硬盘的挂住故障，以便及时处理故障；且，本申请实施例提供的挂住故障检测方法可以配置在目标硬盘的管理进程中自动执行，既不需要依赖硬盘厂商提供检测工具，也不需要在硬盘上增加新硬件，也不需要人为干预，简单易行，不会影响硬盘的生产及使用成本。

在本申请一个可行的实施方式中，上述分布式存储系统硬盘挂住故障检测方法，还可以包括以下步骤：

S104、为所述目标硬盘设置对应的IO线程组。

S105、通过所述IO线程组读取并处理所述目标硬盘对应的各个访问请求，以完成对所述目标硬盘的读写操作。

为便于对硬盘进行管理、实现读写(I/O)服务，本申请实施例为目标硬盘设置专用的IO线程组，也即在目标硬盘的管理进程中创建一组IO线程，共享该管理进程的系统资源，并用于仅用于处理对该目标硬盘的访问请求；相对于现有技术通过一组IO线程同时服务于所有硬盘读写操作，或者直接使用用户线程服务于硬盘读写操作，本申请实施例为每个硬盘分别设置IO线程组，可以避免因非硬盘故障或者某一个硬盘故障导致IO线程被挂住，进而影响所有硬盘的读写操作的现象。另外，IO线程组中的各个线程并行执行不同的访问请求，一方面可以提高访问请求处理效率，即提高硬盘的读写速度，另一方面还可以在某个线程在执行某个访问请求并被挂住时，其他线程可以不受影响继续处理其他访问请求。

相应的，基于上述IO线程组，上述步骤S101所述的检测目标硬盘对应的各个访问请求的执行时间，具体可以为检测其IO线程组对各个访问请求的执行时间。

进一步的，在本申请另一个可行的实施例中，上述检测方法还可以包括：针对每个目标磁盘，设置对应的输入队列。

如图2所示的本申请实施例中任一个数据存储节点Y中访问请求(IO请求)处理流程示意图，对于数据存储节点Y中的一个磁盘X，设置一组IO线程，为便于区分，图2中将其分别编号为T1～Tn；相应的，每个IO线程对应设置一个输入队列，即图2中编号为Q1至Qn的n个IO队列，与IO线程一一对应。数据存储节点Y接收到来自客户端的IO请求后，先对该IO请求进行处理，确定其访问对象为哪个磁盘的哪部分数据，并将对同一磁盘的同一种数据的不同IO请求放入同一IO队列中，实现对同一数据的串行访问，从而可以避免两个IO请求同时访问同一数据。另外，对于数据存储节点Y，其还可以存在不绑定任一磁盘的IO线程(T0)及相应的IO队列(Q0)，实现对整个节点Y的相关操作。一个完整的分布式存储系统可以包括与数据存储节点Y并列的多个数据存储节点，每个数据存储节点的IO请求处理流程均可采用图2所示流程。

相应的，上述步骤S101所述的检测目标硬盘对应的各个访问请求的执行时间，具体可以为：检测目标硬盘的输入队列中处于队头位置的访问请求的执行时间。

其中，所述输入队列可以设置为先进先出(First Input First Output，FIFO)队列。以图2中IO队列Q1为例，不同访问请求按照时间顺次依次存入Q1中，其中进入Q1越早的访问请求越接近该Q1的队头，再相应的IO线程T1每次从Q1的队头位置读取一个访问请求并执行，完成相应的磁盘操作H1；同时，在每次读出队头的访问请求时，开始对T1中该访问请求的执行时间进行计时，直至该访问请求执行结束，如果计时达到预设阈值时，该访问请求仍未执行完毕，说明该访问请求的执行时间超过预设阈值，则可以判定该访问请求为时滞请求，相应的IO线程T1被挂住，进而可以判定磁盘X出现挂住故障。

可见，本申请实施例基于目标硬盘的输入队列，根据其访问请求的出队顺序执行并对其执行时间进行计时，可以准确得到每个访问请求的执行时间，从而及时发现时滞请求，确定硬盘挂住故障，为及时处理出现挂住故障的硬盘奠定了基础。

本申请实施例还提供了一种分布式存储系统硬盘挂住故障处理方法，图3示出了该挂住故障处理方法的一种流程图。

如图3所示，该挂住故障处理方法包括以下步骤：

S201、当目标硬盘出现挂住故障时，将所述目标硬盘的状态标记为挂住故障状态。

S203、清理所述目标硬盘对应的被挂住管理进程所占用的系统资源。

基于以上分布式存储系统硬盘挂住故障检测方法或者其他可行的检测方法，当判定某个硬盘出现挂住故障时，可以继续执行本实施例提供的处理方法。具体的，步骤S201实际为硬盘状态管理操作，对出现挂住故障的硬盘标记挂住故障状态；其中，硬盘一旦被标记为挂住故障状态，则不允许其再重新标记为正常状态，从而可以避免再次出现挂住故障。步骤S203实际为对被挂住硬盘的资源清理操作：依据上述检测方法的实施例所述，当目标硬盘出现挂住故障时，必然存在至少一个时滞请求，也即目标硬盘的管理进程被挂住，通过清理该被挂住管理进程所占用的系统资源，如关闭已打开的文件句柄等。

步骤S203中清理系统资源的作用在于，一方面，可以对被挂住管理进程所占用的系统资源进行重新分配，以供其他进程应用；另一方面，被挂住进程占用的系统资源被清理完毕后，该被挂住管理进程即自动退出，也即解除了该进程的挂住状态，进而可以创建并启动新的管理进程来管理该目标硬盘。

可见，本申请实施例提供的硬盘挂住故障处理方法，一方面通过状态标记避免故障硬盘再次被访问，另一方面清理故障硬盘占用的系统资源，使得其他进程可以重新分配应用这些系统资源，降低硬盘挂住故障可能带来的不利影响，达到止损目的。且，上述处理方法既不需要依赖硬盘厂商提供检测工具，也不需要在硬盘上增加新硬件，也不需要人为干预，简单易行，不会影响硬盘的生产及使用成本。

在本申请一个可行的实施例中，上述步骤S201中，在将目标硬盘的状态标记为挂住故障状态后，还可以继续执行以下步骤：将该挂住故障状态保存至正常的硬盘。

上述正常的硬盘具体可以为整个分布式存储系统的系统硬盘，也可以为与该目标硬盘存在通信连接的其他硬盘。上述在硬盘直接实现状态同步，可以保证被挂住的硬盘即使临时变成可用状态也不能再被用到，从而避免再次出现挂住故障。

进一步的，在本申请一个可行的实施例中，上述步骤S203中清理所述目标硬盘对应的被挂住管理进程所占用的系统资源，具体可以包括以下步骤：

S2031、申请新内存，并通过所述新内存执行下述步骤S2032及S2033。

本申请通过新内存执行具体的清理步骤，而不是。

S2032、查找得到所述被挂住进程占用的全部内存段。

目标硬盘的管理进程被分配的内存空间通常为多个内存段，要实现完全清理，需要查找到全部的内存段；具体的，在Linux操作系统下可以从/proc/self/smaps这个文件中得到所述内存段。

S2033、分别解除每个内存段对应的内存映射。

为管理进程分配系统资源时，通常是通过mmap操作在某项系统资源(如一个文件) 与一个内存段之间建立映射关系；相应的，清理内存占用时，可以通过munmap解除各个内存段对应的内存映射关系。

可见，上述步骤S2032和S2033实际为通过新内存执行清理被挂住管理进程所占用的内存资源的操作，该操作的执行过程也不需要额外的硬件工具以及人为干预，简单易行；且相对于直接在该目标硬盘的管理进程原来被分配的内存中执行该操作，可以避免执行该清理步骤的线程也随管理进程被挂住。

参照图4，在本申请另一个可行的实施例中，上述分布式存储系统硬盘挂住故障处理方法，还包括以下步骤：

S202、弹出所述目标硬盘的输入队列中缓存的各个访问请求，并返回所述目标硬盘的故障信息。

由于目标硬盘的管理进程被挂住，目标硬盘的输入队列中缓存的各个请求(即还未来得及处理的请求)也无法继续被处理，本实施例将这些访问请求弹出，并向用户返回该目标硬盘的故障信息，如“硬盘出错”等，从而可以避免相关用户继续等待未处理请求的响应，以及避免用户再次向该目标硬盘发送访问请求。

仍参照图4，在本申请另一个可行的实施例中，上述处理方法还包括：

S204、在每次启动所述目标硬盘的管理进程后，确定所述目标硬盘的状态，并在所述目标硬盘的状态为挂住故障状态时，禁止对所述目标硬盘的访问。

上述步骤S204实现了对目标硬盘的可用性监督，既可以执行于新硬盘启用时，用于启动对目标硬盘挂住故障检测步骤，以实现对目标硬盘可用性的实时监督；步骤S204还可以执行于上述步骤S203之后，即重启故障硬盘的管理进程后，由于在步骤S201中故障硬盘已被标记为挂住故障状态，故可通过步骤S204，拒绝一切针对该故障硬盘的访问请求，避免该故障硬盘再次被访问而再次引起进程挂住。

另外，图5通过时序图的形式展示了本申请实施例所述的分布式存储系统硬盘挂住故障检测及处理流程。参照图5，当一个数据存储节点的管理进程启动后，相应建立并启动Hang盘检测线程，周期性检测该数据存储节点中是否存在出现挂住故障的磁盘(Hang盘)；其中，该Hang盘检测线程所执行的检测操作具体包括，针对磁盘的各个IO线程，检测是否存在长时间未返回执行结果的请求(即时滞请求)，如果磁盘X的某个IO线程中存在时滞请求，说明磁盘X被Hang住，则启动Hang盘清理线程，清理整个数据存储节点管理进程所占用的各种资源、内存(memory)、函数依赖关系(Functional Dependency，FD)等，并在系统盘上记录磁盘X的状态为挂住故障状态(Hang状态)；然后重启当前的管理进程，得到新的管理进程，新的管理进程启动后，首先识别该存储节点中各个磁盘的状态，以禁用(忽略)标记为Hang状态的磁盘。

通过以上的方法实施例的描述，所属领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，并存储在一个存储介质中，包括若干指令用以使得分布式存储系统执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：只读存储器(ROM)、随机存取存储器(RAM)、磁碟或者光盘等各种可以存储数据和程序代码的介质。

图6为本申请一示例性实施例示出的一种分布式存储系统硬盘挂住故障检测装置的结构框图。如图6所示，所述检测装置包括：检测单元101和比较单元102。

其中，检测单元101用于，检测目标硬盘对应的各个访问请求的执行时间；

比较单元102用于，判断是否存在执行时间大于对应的预设阈值的时滞请求，如果存在所述时滞请求，则确定所述目标硬盘出现挂住故障。

由以上技术方案可知，本申请实施例通过检测目标硬盘对应的访问请求的执行时间来判断该目标硬盘是否出现挂住故障，可以及时发现目标硬盘的挂住故障，以便及时处理故障；且，本申请实施例既不需要依赖硬盘厂商提供检测工具，也不需要在硬盘上增加新硬件，也不需要人为干预，简单易行，不会影响硬盘的生产及使用成本。

在本申请一个可行的实施方式中，上述检测装置还可以包括：进程管理单元；该进程管理单元用于，创建所述目标硬盘对应的IO线程组，并通过所述IO线程组读取并处理所述目标硬盘对应的各个访问请求，以完成对所述目标硬盘的读写操作。

在本申请另一个可行的实施方式中，上述检测装置中的检测单元101具体可以配置为：检测目标硬盘的输入队列中处于队头位置的访问请求的执行时间。

即在通过基于FIFO规则的输入队列缓存目标硬盘的访问请求时，目标硬盘的管理进程(更具体的，可以是上述IO线程组)仅从输入队列的队头位置读取访问请求并开始执行，故在队头的访问请求被读出时，开始对该访问请求的执行时间进行计时，直至该访问请求执行结束，如果计时达到预设阈值时，该访问请求仍未执行完毕，说明该访问请求的执行时间超过预设阈值，则可以判定该访问请求为时滞请求，进而可以判定相应的目标硬盘出现挂住故障。

图7为本申请一示例性实施例示出的一种分布式存储系统硬盘挂住故障处理装置的结构框图。如图7所示，所述处理装置包括：状态管理单元201和资源清理单元203。

其中，状态管理单元201用于，当硬盘出现挂住故障时，将所述出现挂住故障的目标硬盘的状态标记为挂住故障状态；

资源清理单元203用于，清理所述目标硬盘对应的被挂住管理进程所占用的系统资源，以便启动新的用于管理所述目标硬盘的管理进程。

由以上技术方案可知，本申请实施例提供的硬盘挂住故障处理装置，一方面通过状态标记避免故障硬盘再次被访问，另一方面清理故障硬盘占用的系统资源，使得其他进程可以重新分配应用这些系统资源，降低硬盘挂住故障可能带来的不利影响，达到止损目的。且，上述处理装置既不需要依赖硬盘厂商提供检测工具，也不需要在硬盘上增加新硬件，也不需要人为干预，简单易行，不会影响硬盘的生产及使用成本。

在本申请一个可行的实施方式中，上述状态管理单元201在将目标硬盘的状态标记为挂住故障状态后，还可以将该挂住故障状态保存至正常的硬盘。

本实施例通过不同硬盘直接的状态同步，可以保证被挂住的硬盘即使临时变成可用状态也不能再被用到，从而避免再次出现挂住故障。

在本申请一个可行的实施方式中，为实现清理所述目标硬盘中被挂住管理进程占用的系统资源，所述资源清理单元203具体被配置为，申请新内存，并通过所述新内存执行下述两步操作，以清除所述被挂住管理进程占用的内存资源：查找得到所述被挂住进程占用的全部内存段，以及分别解除每个内存段对应的内存映射。

参照图8，在本申请另一个可行的实施方式中，上述故障处理装置还可以包括：请求清理单元202。该请求清理单元202用于，弹出所述目标硬盘的输入队列中缓存的各个访问请求，并返回所述目标硬盘的故障信息。

仍参照图8，上述故障处理装置还可以包括：可用性监督单元204；该可用性监督单元204用于，在每次启动所述目标硬盘的管理进程后，确定所述目标硬盘的状态，并在所述目标硬盘的状态为挂住故障状态时，禁止对所述目标硬盘的访问。

可见，通过上述可用性监督单元，可以实现对目标硬盘可用性的实时监督，并在目标硬盘出现挂住故障时，拒绝一切针对该故障硬盘的访问请求，避免该故障硬盘再次被访问而再次引起进程挂住。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于装置或系统实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。

以上所述仅是本申请的具体实施方式，使本领域技术人员能够理解或实现本申请。对这些实施例的多种修改对本领域的技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本申请的精神或范围的情况下，在其它实施例中实现。因此，本申请将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

Claims

一种分布式存储系统硬盘挂住故障检测方法，其特征在于，包括：

检测目标硬盘对应的各个访问请求的执行时间；

判断是否存在执行时间大于对应的预设阈值的时滞请求；

如果存在所述时滞请求，则确定所述目标硬盘出现挂住故障。
根据权利要求1所述的检测方法，其特征在于，还包括：

创建所述目标硬盘对应的IO线程组；

通过所述IO线程组读取并处理所述目标硬盘对应的各个访问请求，以完成对所述目标硬盘的读写操作。
根据权利要求1或2所述的检测方法，其特征在于，检测目标硬盘对应的各个访问请求的执行时间，包括：

检测目标硬盘的输入队列中处于队头位置的访问请求的执行时间。
一种分布式存储系统硬盘挂住故障处理方法，其特征在于，包括：

当目标硬盘出现挂住故障时，将所述目标硬盘的状态标记为挂住故障状态；

清理所述目标硬盘对应的被挂住管理进程所占用的系统资源，以便启动新的用于管理所述目标硬盘的管理进程。
根据权利要求4所述的故障处理方法，其特征在于，清理所述目标硬盘对应的被挂住管理进程所占用的系统资源，包括：

申请新内存，并通过所述新内存执行下述两步操作，以清除所述被挂住管理进程占用的内存资源；

查找得到所述被挂住进程占用的全部内存段；

分别解除每个内存段对应的内存映射。
根据权利要求4或5所述的故障处理方法，在清理所述目标硬盘对应的被挂住管理进程所占用的系统资源之前，还包括：

弹出所述目标硬盘的输入队列中缓存的各个访问请求，并返回所述目标硬盘的故障信息。
根据权利要求4或5所述的故障处理方法，其特征在于，还包括：

在每次启动所述目标硬盘的管理进程后，确定所述目标硬盘的状态；

如果所述目标硬盘的状态为挂住故障状态，则禁止对所述目标硬盘的访问。
根据权利要求4或5所述的故障处理方法，其特征在于，还包括：

将所述目标硬盘的挂住故障状态保存至正常的硬盘。
一种分布式存储系统硬盘挂住故障检测装置，其特征在于，包括：

检测单元，用于检测目标硬盘对应的各个访问请求的执行时间；

比较单元，用于判断是否存在执行时间大于对应的预设阈值的时滞请求，如果存在所述时滞请求，则确定所述目标硬盘出现挂住故障。
根据权利要求9所述的故障检测装置，其特征在于，还包括：

进程管理单元，用于创建所述目标硬盘对应的IO线程组，并通过所述IO线程组读取并处理所述目标硬盘对应的各个访问请求，以完成对所述目标硬盘的读写操作。
根据权利要求9或10所述的故障检测装置，其特征在于，为实现检测目标硬盘对应的各个访问请求的执行时间，所述检测单元具体被配置为：

检测目标硬盘的输入队列中处于队头位置的访问请求的执行时间。
一种分布式存储系统硬盘挂住故障处理装置，其特征在于，包括：

状态管理单元，用于当目标硬盘出现挂住故障时，将所述目标硬盘的状态标记为挂住故障状态；

资源清理单元，用于清理所述目标硬盘对应的被挂住管理进程所占用的系统资源，以便启动新的用于管理所述目标硬盘的管理进程。
根据权利要求12所述的故障处理装置，其特征在于，为实现清理所述目标硬盘中被挂住管理进程所占用的系统资源，所述资源清理单元具体被配置为，

申请新内存，并通过所述新内存执行下述两步操作，以清除所述被挂住管理进程占用的内存资源：查找得到所述被挂住进程占用的全部内存段，以及分别解除每个内存段对应的内存映射。
根据权利要求12或13所述的故障处理装置，其特征在于，还包括：

请求清理单元，用于弹出所述目标硬盘的输入队列中缓存的各个访问请求，并返回所述目标硬盘的故障信息。
根据权利要求12或13所述的故障处理装置，其特征在于，还包括：

可用性监督单元，用于在每次启动所述目标硬盘的管理进程后，确定所述目标硬盘的状态，并在所述目标硬盘的状态为挂住故障状态时，禁止对所述目标硬盘的访问。
根据权利要求12或13所述的故障处理装置，其特征在于，所述状态管理单元，还用于：

将所述目标硬盘的挂住故障状态保存至正常的硬盘。