CN113179665A - 使用基于纠错的度量来识别性能不佳的数据存储设备 - Google Patents

Abstract

本发明公开了一种用于识别数据存储***中性能不佳的数据存储设备(DSD)(诸如硬盘驱动器(HDD)和/或固态驱动器(SSD))的方法，涉及从多个DSD中的每个DSD检索和评估相应的一组日志页面，诸如SCSI Log感测计数器。基于每个相应的一组日志页面，为每个相应的DSD确定服务质量(QoS)度量的值，其中每个QoS值表示在相应DSD不执行自主纠错的情况下被处理的字节的平均百分比。响应于特定DSD达到预先确定的阈值QoS值，可确定特定DSD的原位修复，或者可将特定DSD添加到候选DSD列表中以用于进一步检查，这可包括针对适当配置的DSD的FRPH检查。

Description

使用基于纠错的度量来识别性能不佳的数据存储设备

相关申请的交叉引用

本申请是2019年6月26日提交的标题为“Use Of Recovery Behavior ForPrognosticating And In-Situ Repair of Data Storage Devices”的待审美国专利申请16/453,368的部分继续申请并且要求该待审美国专利申请的优先权的权益，该待审美国专利申请的全部内容以引用方式并入，以用于本文完全阐述的所有目的。

技术领域

本发明的实施方案可整体涉及数据存储***，并且更具体地涉及识别运行上有问题的数据存储设备的方法。

背景技术

存在对高容量数字数据存储***的商业需求，其中多个数据存储设备(DSD)(或者，通常是，“驱动器”)容纳在共同的壳体中。数据存储***通常包括容纳多个搁架的大型壳体，多行DSD安装在该搁架上。使用数据存储***的典型方法是移除或停止使用在现场发生故障或失效的DSD。然后，通常由内部实验室或客户部署站点的技术人员以替换DSD更换此类DSD。失效驱动器通常被客户销毁或返回给制造商进行失效分析。

本节中描述的任何方法是可以实行的方法，但不一定是先前已经设想到或实行过的方法。因此，除非另有说明，否则不应认为本节所述的任何方法仅仅因为包含在本节中而成为现有技术。

附图说明

实施方案通过示例而非限制的方式在附图中示出，在附图中相同的附图标记指代相似的元件并且其中：

图1A是根据一个实施方案的示出硬盘驱动器(HDD)的平面图；

图1B是根据一个实施方案的示出固态驱动器(SSD)的框图；

图2为根据一个实施方案的示出数据存储***的透视图；

图3是根据一个实施方案的示出数据存储***架构的框图；

图4是根据一个实施方案的示出识别有问题的硬盘驱动器的方法的流程图；

图5是根据一个实施方案的示出识别性能不佳的数据存储设备的方法的流程图；并且

图6是根据一个实施方案的示出识别性能不佳的数据存储设备的方法的流程图。

具体实施方式

本发明描述了识别有问题的使用中的数据存储设备的方法。在以下描述中，出于解释的目的，阐述了许多具体细节，以便提供对本文所述的本发明实施方案的透彻理解。然而，将显而易见的是，本文所述的本发明的实施方案可以在没有这些具体细节的情况下实践。在其他情况下，熟知的结构和设备以框图的形式示出，以便避免不必要地模糊本文所述的本发明的实施方案。

示例性操作上下文数据存储***的物理描述

存在对高容量数字数据存储***的商业需求，其中多个数据存储设备(DSD)诸如硬盘驱动器(HDD)和/或固态驱动器(SSD)容纳在共同的壳体中。数据存储***通常包括容纳多个搁架的大型壳体，多行DSD安装在该搁架上。图2为根据实施方案的示出数据存储***的示例的透视图。数据存储***200可以包括***壳体202(或“机架202”)，多个数据存储***托盘204容纳在该***壳体中。例如，每个托盘204可被放置或滑动到机架202内的对应狭槽中。机架202还容纳***控制器，并且还可容纳开关、存储服务器、应用服务器、电源、冷却风扇等。

图3是根据一个实施方案的示出数据存储***架构的框图。示例性架构300示出了包括多个硬盘驱动器(DSD)304a(HDD1)、304b(HDD2)和304n(HDDn)的数据存储***200，其中n表示可因具体实施而异的任意数量的HDD(和/或SSD)。每个HDD 304a-304n根据对应的通信协议323经由通信接口322与数据存储***控制器312通信并处于该数据存储***控制器的控制下。每个HDD 304a-304n包括对应非易失性存储器(NVM)306(例如，在HDD的情况下，通常为旋转磁盘介质的形式)，其由包括日志模块310的相应HDD控制器308控制。每个日志模块310(其可以是例如对应片上***(SoC)的构成，诸如数据信道电路或硬盘控制器电路的一部分，如图所示，在HDD的上下文中)能够记录HDD控制器308采取的动作，诸如记录读取、写入和查找错误、相关联的恢复动作以及其他近期和长期HDD状态信息。数据存储***200的***控制器312包括存储器313、处理器315和可靠性引擎314以及相关联的FRPH(每小时全恢复)模块316，它们共同表示涉及HDD 304a-304n的预后和原位修复的过程功能，如本文其他地方更详细描述的。

在本文中被描述为由***控制器312或HDD 304a-304n执行或可执行的处理、功能、过程、动作、方法步骤等可包括通过执行存储在一个或多个存储器单元中的一个或多个指令序列来执行，并且当由一个或多个处理器执行时，导致此类性能。***控制器312可以软件、硬件和固件的任何形式和/或组合来实施。例如，并且根据一个实施方案，***控制器312包括专用集成电路(ASIC)，该专用集成电路包括用于存储此类指令(作为非限制性示例，诸如固件)的至少一个存储器单元和用于执行此类指令的至少一个处理器，启用关于多个HDD 304a-304n的潜在有问题的HDD的预后(例如，“静默”故障驱动，其内部可能正在努力完成数据事务，但尚未公开故障)，并且管理、控制、促进与已发生故障和故障中的HDD对应的原位修复动作。

数据存储***200可与主机350通信地耦接，该主机可被实施为在其上执行可执行代码的硬件机器(对于非限制性示例，计算机或硬件服务器，等等)，或作为可由一个或多个处理器(对于非限制性示例，软件服务器诸如数据库服务器、应用程序服务器、媒体服务器等)执行的软件指令。主机350通常表示数据存储***200的客户端，并且具有向数据存储***200提出读取和写入请求(输入/输出或“IO”)的能力。需注意，***控制器312也可被称为“主机”，因为该术语通常参考对数据存储设备或设备阵列进行IO调用的任何设备来使用，例如HDD 304a-304n。

背景技术

如本文所使用的，术语“基本上”应当理解为描述大部分或差不多被结构化、配置、定尺寸等的特征，但在实践中制造公差等引起结构、构型、尺寸等并不总是或一定如所述的那样精确的情形。例如，将结构描述为“基本上竖直的”将为该术语赋予其普通含义，使得侧壁对于所有实用目的均为竖直的，但可能并不精确地处于90度。

虽然诸如“最佳”、“优化”、“最小”、“最小化”等术语可能不具有与其相关联的某些值，但是如果这些术语在本文中使用，则意图是本领域普通技术人员将理解此类术语将包括在与本公开的整体一致的有益方向上影响值、参数、度量等。例如，将某事物的值描述为“最小”并不要求该值实际上等于某个理论最小值(例如，零)，但应在实际意义上理解为对应的目标是在有益方向上朝向理论最小值移动该值。

一些数据存储***实施诊断和原位(例如，“就位”或“在适当位置”)修复规程。这意味着在现场操作期间已发生故障的***HDD在现场被诊断和修复到可能的程度，并且如果它们不能被修复，则它们被原位停用而不是被替换。优选地，原位修复需要自动化或半自动化过程，而所关注的HDD保留在***外壳中。许多HDD修复不会导致容量或性能的任何损失。HDD可以仍然允许***软件继续使用的方式被修复，尽管容量或性能降低。可允许无法修复的HDD在***内的适当位置发生故障，诸如在其中***附带过度配置的存储容量的情况下，尽管存在许多驱动器故障，但该过度配置的存储容量允许完整的指定存储容量的可用性。原位修复可消除调度服务技术人员替换现场故障的驱动器的成本，以及这些替换驱动器的成本。另外，原位修复可以减少存储设备的AFR(年故障率)，并且将可能在未来产品发布采用“现场故障”模型时消除ARR(年返修率)。

HDD中原位修复的具体实施可使数据存储***中必要的过度配置量最小化以能够提供寿命硬件保证。如所提及的，一些存储***(和/或存储***操作***软件)可能能够在许多HDD发生故障之后继续使用这些HDD。对故障驱动器的分析显示，在现场故障的许多HDD可用相对简单的技术恢复至完全或部分使用。

数据存储设备(DSD)性能不佳的相当常见的表现形式导致数据存储***表现出性能不佳。识别故障设备的现有方法是显著资源密集型的。数据存储***遇到表现出过多平均IO完成时间(延迟)的一组HDD。这可相对于读取操作或写入操作或两者而发生。这种行为的发生是因为每当访问有故障的、边缘的或易错的磁头或表面时，驱动器正在调用对数据恢复程序(DRP)动作的高利用率。这种类型的设备在本文中被称为“性能不佳的驱动器”。

性能不佳的驱动器通常足以正常运行，使得它们不产生主机可见的硬错误(例如，检查条件+KCQ(密钥代码验证器)，IO完成延迟也不超过HBA(主机总线适配器)超时阈值(约5秒-10秒)。然而，这些驱动器通常表现出比它们的对等驱动器高得多的平均延迟，足以引起重大问题。在使用擦除编码和/或RAID技术的***中，若干关联驱动器必须各自执行一个或多个IO请求以满足单个更高级操作(例如，S3操作)的需要。另外，一些外部主机操作类型无法完成，直到所有成员驱动器已成功完成其在操作中所分配的角色。因此，较慢完成一些或大多数IO请求的驱动器可增加外部主机操作的完成时间。当数据存储***尝试自主地执行管理操作如对象验证或重建时，性能不佳的驱动器还可导致资源瓶颈或甚至匮乏。

目前，数据存储***的主机无法精确检测到性能不佳的驱动器。这通常是因为驱动器健康检测方法基于主机可见的硬错误或命令协议超时的检测。因此，性能不佳的驱动器很难识别，并且相关联的服务单通常需要对目标机器进行手动干预。

避免尾延迟过长

存储行业通常将性能不佳的驱动器定义为表现出高“尾延迟”的驱动器。尾延迟是指其中大多数IO在合理时间内完成但有极小比例以不可接受的高延迟完成的现象。驱动器尾延迟的典型OEM客户规格可以读取一些内容，大致是“最大命令队列深度为16，允许最多仅1:100k个单块随机读取超过1000毫秒(msec)完成时间”。

通常，由于有意的驱动器行为，会发生高尾延迟，如下所述：

(a)IO请求针对距当前磁头位置的查找距离的优先级。HDD通常优化命令执行以使查找和旋转延迟最小化。此类策略可能推迟满足不方便的IO请求。仅在IO请求的时效已经超过固定的最大完成时间(可能为2-3秒)之后，该IO请求才升高到高优先级，因此它可以快速完成以避免主机超时。

(b)IO请求针对驱动器后台活动的优先级。DSD通常使主机IO优先于后台活动。然而，如果主机加载请求在临界时间到达，或者如果该请求流在长时间段内足够持久，则最终一些或所有主机IO请求将被推迟，直到至少一些后台活动已被允许运行。

避免高尾延迟的一种方法可涉及队列深度的最小化。如果HDD仅被给予少量IO以同时处理(极端情况仅为1)，则驱动器将没有机会选择优选的查找模式。这导致更确定的延迟，代价是较低的吞吐量。最近提出的减轻尾延迟效应的方法是允许主机为其向驱动器发出的每个命令指定特定的最大超时。如果驱动器不能在分配的时间内完成操作，则驱动器将“快速故障”，这向主机发出信号以重建来自冗余源的数据。

主机对平均延迟的监测

另一种行业方法涉及用外部工具如Linux内置“iostat”工具来监视磁盘，该工具将事务的平均IO延迟(在任意时间窗口上更新)报告给每个DSD。然而，所报告的延迟包括后端栈的所有部分，例如，被测量的延迟从Linux驱动程序开始到HBA驱动程序、HBA、DSD、从DSD返回、通过HBA及其驱动程序返回并最终返回到Linux驱动程序。DSD外部的操作的延迟可以与DSD本身的延迟相当或大于DSD本身的延迟。这使得难以或不可能隔离可归因于性能不佳的DSD的确切延迟。基于“iostat”的统计也无法区分驱动器引起的延迟的各种原因，诸如由重IO负载模式呈现的内部纠错、后台任务或拥塞。

SMART主机监测

另一种方法是依赖于SMART(自我监测、分析与报告技术)，一种机载自诊断子***。作为一种技术，SMART能够提醒主机DSD的性能下降。然而，SMART的现有现实世界具体实施仅限于提供使用单个外壳命令序列收集健康相关统计数据的合并报告的方式。实际上，SMART在预测或诊断故障驱动方面的能力非常有限，尤其是未表现出硬错误的性能不佳。

可靠性引擎

参考图3，根据一个实施方案，被称为可靠性引擎314的软件组件负责执行或管理数据存储设备(DSD)诊断、预后和修复操作。关于诊断，当***(例如，数据存储***200的***控制器312)检测到数据存储***200的DSD 304a-304n的问题时，***调用可靠性引擎314并传递描述***对该DSD的问题的信息。通常，可靠性引擎314可以进入关于该DSD的诊断状态并分析DSD以识别问题的根本原因。关于修复，一旦识别出问题的根本原因，可靠性引擎314就向***控制器312通知建议的修复动作的逻辑，***控制器312可基于***事件(例如，代码上传、即将发生的关机/重启)和***内磁盘冗余级别根据紧急性级别调度该建议的修复动作。一旦***控制器312请求修复，DSD通常离线并且可靠性引擎314进行修复(这可能需要几秒到几天的任何时间)。在修复和修复后诊断结束时，DSD可以恢复到完全使用、恢复到以降低的容量和/或性能使用，或者DSD可以从***停用。

根据实施方案，关于预后，可靠性引擎314还在每个DSD在线并被***使用时周期性地监测每个DSD的健康。在硬盘驱动器(HDD)的上下文中，这可通过读取和分析HDD的内部E6日志317的限时子集来完成，诸如结合FRPH模块316或在该FRPH模块的帮助下，如本文其他地方更详细描述的。类似地，进一步在固态驱动器(SSD)的上下文中，这可以通过读取和分析DSD的日志感测计数器319来完成，诸如结合QoS(服务质量)模块318或在该QoS(服务质量)模块的帮助下进行，如本文其他地方更详细描述的。因此，可靠性引擎314可以主动检测例如DSD中的延迟问题或错误率问题，该问题可能(或可能不)影响主机可见性能，但是对于***而言不够严重到使DSD发生故障。例如，在访问介质的特定磁头或区域时一致地进入高DRP(数据恢复过程)级别的HDD通常将表现出比其对等驱动器更高的IO完成延迟。在一些存储***的擦除编码或基于RAID的***中，主机可见延迟通常由数据集中最慢DSD的性能限定。可靠性引擎314可以异步通知***控制器312该DSD的推荐修复操作的逻辑。一旦***允许可靠性引擎314继续进行修复，例如，以移除HDD的高延迟磁头/表面，主机可见延迟劣化就被解决。

硬盘驱动器预后工具：每小时全恢复

图4是根据一个实施方案的示出识别有问题的硬盘驱动器的方法的流程图。图4的过程或流程可被实现为作为存储在一个或多个存储器单元中的一个或多个指令序列来执行，并且当由一个或多个处理器执行时，使得该过程执行。例如，存储在一个或多个存储器单元(例如，控制器固件固有的ROM)中并且当由一个或多个处理器(例如，图3的***控制器312的处理器315)执行时可使得执行图4所示的过程的指令序列(例如，体现在图3的***控制器312的固件中的可靠性引擎314)。

此外，设想了识别有问题的固态驱动器(SSD)的类似方法，该方法根据硬盘驱动器和固态驱动器底层的不同技术进行了适当修改。例如，对于HDD，DRP步骤增加主机可见延迟的主要原因是由于必须等待介质的附加旋转以重试操作的旋转延迟。相比之下，在SSD的上下文中不存在旋转延迟，因此主机可见延迟的关键原因是主机IO必须等待SSD正在执行的其他活动的场景，诸如主机IO请求与后台任务冲突(例如，垃圾回收、单元刷新、读取干扰等)，主机IO请求与其他主机IO请求冲突，并且由于非易失性存储器部件由于老化和/或磨损而表现出劣化而需要更长的编程/擦除操作而导致延迟增加。因此，除了SSD之外，可使用与FRPH功能等效的度量来量化存储***SSD中延迟的可变性(以及，同样地QoS(服务质量)的可变性)。

在框402处，从多个硬盘驱动器中的每一个硬盘驱动器检索相应的恢复日志。例如，数据存储***200(图2和图3)的***控制器312(图3)从多个HDD 304a-304n(图3)中的一个或多个的日志模块310(图3)检索E6日志317(图3)。E6日志317是指用于快照HDD的状态的二进制文件的具体实施。E6日志317包含大量(数十个)子区段，包括介质错误日志，并且通常在10MB至100MB的大小范围(数量级)内，这取决于获取哪些“模式”(区段组)。还存在增量E6日志能力，该增量E6日志能力仅获取“新”的状态，即，自最近的全量或增量获取以来。增量E6日志可小至几MB，但可至多达全量E6日志317的大小。E6日志317的区段具有各种主题/目的，一些是全局固定大小的“驱动器寿命”状态，并且一些随着更多驱动器活动的积累而随时间推移而增长。区段的数据元中的一些数据元在驱动器的寿命期间被保留，并且一些数据元被包裹，因为HDD自主删除较旧状态以避免超过尺寸的边界上限。根据一个实施方案，E6日志317的介质错误日志部分在下文中用来计算以下FRPH(每小时全恢复)度量，并且在功能上被称为“恢复日志”，因为E6日志317的该特定部分或区段记录由对应HDD内的每个读写磁头执行的数据恢复步骤(例如，查找恢复、读取恢复、写入恢复)。

在框404处，基于每个相应的恢复日志，针对多个HDD中的每个相应HDD的每个相应读写磁头确定被称为FRPH的度量的值。例如，如下文所述，基于在框402处检索的恢复日志，针对多个HDD 304a-304n中的一个或多个的每一个HDD的每个读写磁头(例如，图1的读写磁头110a)计算FRPH值。DRP或恢复“步骤”是HDD动态调用以从在执行先前步骤之后不可读的一个或多个扇区恢复数据的动作。例如，可存在HDD/磁头可用的数百个可能的DRP步骤，其可更一般地分类在类别中的一个中以用于读取、写入和查找恢复步骤，其中较高的步骤编号表示较多涉及的恢复算法，并且因此比较低编号的DRP步骤花费较长的时间来执行。根据一个实施方案，“全恢复”是所有可能的DRP步骤的执行。如果全恢复不成功，则主机接收到指示无法传输数据的硬错误。

在框404a处，对磁头执行的所有恢复步骤上花费的时间量在特定时长(即，评估周期)上求和。例如，分析相关的恢复日志，并且对于非限制性示例，在操作时间的最后300小时内对由每个HDD磁头(例如，来自E6日志317的HDD介质错误日志区段)执行的所有恢复步骤的严重性(根据恢复步骤的每个“类型”或“级别”花费的时间)求和。根据一个实施方案，评估周期是允许在其上分析恢复步骤的任意时间窗口的可配置参数。

从概念上讲，全恢复意味着已经运行了恢复事件的所有恢复步骤，所需的恢复步骤越多，表明问题相对更严重并且数据恢复将花费的时间越长。然而，根据一个实施方案，出于算法目的，“全恢复”被表征为对应于磁头在一个或多个恢复步骤上花费的预先确定的时长。根据一个实施方案，将一次全恢复确立为磁头在一个或多个恢复步骤上实际花费约2.5秒。然而，出于算法目的而表征全恢复的方式可因具体实施而异。因此，对于磁头花费在恢复步骤上的每个预先确定的时间量(例如，2.5秒的实时)，对“全恢复”进行计数。关于恢复步骤的严重性，如参考示例性***所述，存在数百个可能的DRP恢复步骤，其中较高的步骤编号表示更多涉及的复杂恢复算法，因此，与较低编号的DRP步骤相比，需要更长的时间来执行。此外，恢复步骤被分类为具有类似复杂性的组，并且因此具有类似执行时间。例如，一千个“步骤4”恢复步骤在时间上可等同于一百个“步骤8”恢复步骤。

因此，在框404b处，确定在特定时长内的相等数量的全恢复。参考前述示例，磁头在300小时评估周期内恢复步骤上花费的2.5秒时间单位的数量建立该磁头的全恢复的数量。然后，在框404c处，基于所产生的全恢复的数量和所评估的特定时长，确定磁头的FRPH值，其表示每个磁头平均每小时花费的DRP恢复时间(例如，以最大长度全恢复所花费的时间为单位)例如，在过去300小时内平均每小时花费的DRP恢复时间。因此，在框404处，针对来自待评估的每个HDD 304a-304n的每个磁头迭代框404a-404c。此外，通过检查恢复日志以识别需要任何恢复步骤的每个IO，然后累加执行代表该IO使用的所有恢复步骤的总时间量的估计值来计算FRPH，并且针对HDD中的每个磁头单独计算FRPH度量。

在框404处的FRPH度量值的计算可通过以下方式来实现：分析评估周期的恢复日志，对每个磁头在数百个DRP恢复步骤中的每个中花费的总时间求和，这将有效地产生记录每个磁头对每个恢复步骤/级别的调用次数的柱状图。对于每个恢复步骤，可将估计该特定恢复步骤执行多长时间的恒定时间值乘以该恢复步骤的相应调用，这将产生每个磁头在任何恢复步骤中所花费的总时间量。在所有恢复步骤中花费的总时间量可除以评估周期(例如，300小时)，这将得到每个磁头的在任何恢复步骤中花费的每小时的平均时间量。在所有恢复步骤中所花费的平均时间/小时可通过除以为全恢复建立的时间(例如，2.5秒的“全恢复”的等同物)来归一化，这将产生归一化为评估周期的FRPH值，其中FRPH值为一将意味着平均每小时(例如，在过去的300小时评估周期内)，磁头花费了在恢复操作模式中执行一次全恢复所花费的时间。

在框406处，响应于特定磁头FRPH达到预先确定的FRPH阈值，确定该特定磁头在其中操作的HDD的原位修复。例如，并且根据一个实施方案，具有在特定时长(例如，300小时评估周期)内具有为一(例如，阈值)或更大的FRPH值的一个或多个磁头的HDD被识别为有问题的HDD，即，可能“静默地”发生故障。此外，可使FRPH度量可供客户端查询，诸如经由RESTfulAPI(代表性状态传输应用程序接口)查询，由此客户端将决定FRPH值是否保证减轻动作，并且如果是的话，将需要自己发起此类动作。

根据一个实施方案，如果任何HDD 304a-304n具有FRPH大于或等于一的一个或多个磁头，则识别出在该有问题的HDD中具有最高FRPH的磁头，并且在该磁头上执行“磁头弹出”(磁头脱出)，即，将磁头分类(例如，分类到***控制器312和/或分类到HDD控制器308)为不具有在进一步的IO操作中使用的资格，从而有效地禁用进一步的使用/操作。另选地，根据一个实施方案，原本有问题的HDD可被重新格式化为其当前容量。例如，在其中一个或多个磁头在先前的修复操作中已被“弹出”(脱出)并且此时决定不弹出另一个磁头的情况下，考虑到对应于先前脱出的磁头的减小的容量，HDD可被重新格式化为其当前容量。此外，并且根据一个实施方案，因为可以从介质错误日志确定介质的多少区域以及哪些有问题的区域对FRPH值有贡献，所以另一个修复选项涉及强行省去介质的问题区域(例如，标记区域不可用于进一步的IO)，而不是进行更长并且更复杂的重新格式化或弹出修复。

智能***级可靠性方案

历史存储***可包括具有自主、独立设计的诊断和设备可靠性方案的存储设备，这可导致整个存储***的效率和有效性降低。相比之下，分布在整个存储***中的不同存储设备处和之间的可操作功能的扩展整体视图可导致更有效和更可靠的整体***。

数据存储设备，诸如构成数据存储***200(图2和图3)的DSD304a-304n(图3)，可以被认为是可能影响与每个DSD相关联的数据完整性和可靠性的因素的敏感传感器，诸如HDD的上下文中的温度、气流、振动等，以及SSD的上下文中的年龄、存储周期等。此外，DSD304a-304n可为关于对应于特定介质磁头或区域的位置误差信号(PES)和对其有贡献的因素、DRP恢复操作等的信息源。因此，当与诸如控制器312(图3)的***控制器共享时，每个DSD可能在内部知晓的数据完整性和恢复信息以及它们的组合可以为设备级的数据劣化症状提供廉价但有价值的扩展视力，以用作***级的知情且有效的诊断、预后和修复控制点。还可存在关于在***级可用(例如，对***控制器312可用)的DSD的附加信息，这些信息可有助于和/或组合以有助于***级的智能预测决策。例如，在HDD的上下文中，可使***控制器知晓信息，诸如存储设备形状因素、磁盘数量(和/或致动器)、磁盘的RPM(每分钟转数)以及HDD模型中的其他常见变型，以及每个存储设备在特定搁架和***机架(例如，图2的机架202)内的定位、与风扇的相对接近度、风扇速度、与热源的相对接近度、以及每个设备本身外部的其他因素。需注意，HDD 304a-304n以及***控制器312可被编程为随时间“学习”。因此，可能影响与每个HDD相关的数据可靠性的因素可能不是静态的，即，这些因素(以及基于这些因素的修复决策)可能是随时间动态的。

本文所述的DSD监测诊断/预后修复的闭环性质能够连续监测DSD日志、示出该一个DSD的行为的计算度量，然后将每个DSD的度量与其对等驱动器的度量进行比较以确定“通过/失败”。需注意，每个DSD的事件日志用于计算每个DSD的度量，其中每个DSD仅意识到其自身。这里，***可以看到许多DSD的度量的值，并且将一个DSD的度量与DSD对等驱动器的度量进行比较，其中对等驱动器的定义可以是可变的，例如，通过类似的模型类型、固件修订，并且甚至通过机架内DSD的用例。类似地，每个FRPH度量的计算仅评估一个HDD上磁头的健康状况。然而，诊断主机可通过以下操作来为FRPH度量的构成通过或失败的哪个值设置阈值：考虑每个驱动器的FRPH度量相对于诊断主机可见的较大生态***的异常程度。例如并且根据一个实施方案，通过/失败阈值(即，FRPH阈值)可被设置为等于两个或三个标准偏差的值，该标准偏差高于部署的其余部分的平均(或中值)FRPH评分。

用于检测性能不佳的驱动器的服务质量(QOS)度量

本文描述了由主机软件或DSD(亦称驱动器)本身周期性地计算和监测的服务质量(QoS)度量。QoS度量基于这样的概念：具有完美质量的驱动器将满足100％的主机IO请求而不执行增加延迟的任何错误恢复。即，每当驱动器需要调用DRP时，由那些恢复步骤引起的任何增加的延迟降低提供给主机的服务质量。相对于固定规格或相对于对等驱动器行为，可以主动选择QoS度量值过差或该度量值趋于过差的驱动器，以用于检查本文其他地方所述的FRPH度量。在评估FRPH度量之后，驱动器可经历附加的诊断和修复步骤，和/或被主动移除出积极使用。在不具有获得FRPH度量的能力的***中，可仅基于对其QoS度量的分析主动退出积极使用。

基于日志感测计数器计算QoS度量

根据实施方案，QoS度量由报告为SCSI(小型计算机***接口)“日志感测”计数器(也称为SCSI日志页)的参数来计算，该计数器可使用日志感测命令从SCSI目标设备查询或轮询。这些日志感测计数器(和日志感测命令、支持的日志页面定义和页面参数定义)由长期建立的行业标准来定义，具体地讲，由T10/BSR INCITS SPC(SCSI主命令)来定义。在最近草稿(SPC-4，修订版37a，2014年6月26日公布)(其全文以引用方式并入以用于所有目的，如同在本文完整示出一样)中，表349定义存在“写入错误计数器”(第2页)、“读取错误计数器”(第3页)和“验证错误计数器”(第5页)。表405、表437和表434在相同草稿中其他地方定义了存在这些日志页面中的每个日志页面内报告的公共参数。

根据一个实施方案，QoS度量使用参数代码0001h(校正的可能有延迟的错误)、0004h(校正算法处理的总时间)和0005h(处理的总字节)来计算。当“日志感测”页面和参数组合时，主机可计算总共六个不同QoS度量：三个操作域(读取、写入、验证)中的每一个的2个QoS度量(“可能有延迟”、“处理的总时间”)。根据一个实施方案，每个QoS度量表示为浮点值，其指示在驱动器不执行自主纠错的情况下处理的字节的平均百分比中的“九的数量”。

例如，如果日志感测页面3“读取错误计数器”报告：

参数0001h：校正的可能有延迟的错误：3；

参数0004h：处理的校正算法的总时间：176；

参数0005h：处理的总字节：1TB(1×10¹²)；

然后，在没有自主纠错的情况下传输的字节的百分比是：

(第3页参数0005h-第3页参数0001h)/第3页参数0005h＝

＝((1×10¹²)-3)/(1×10¹²)＝

99.9999999997％。

然后根据一个实施方案，对应的QoS度量将被计算为：

QoS(读取)＝-log10(第3页参数0001h/第3页参数0005h)＝

QoS(读取)＝-log10(3/(1×10¹²))＝

11.52。

关于QoS度量的前述定义的一些考虑因素包括如果QoS公式的输入值中的任一个为零，则无法计算度量值。这种担心的一种解决方法可能是任意地分配恒定QoS值，这意味着“完美QoS”，为此，将指定为此目的具有不完美QoS值的可接受执行驱动器范围的上限值。然而，优选的是，所有驱动器(或至少几乎所有驱动器)具有可计算的QoS度量，因为这增加了统计方法诸如中值、平均值和标准偏差的有效性，以将每个单独的驱动器QoS度量与整个对等驱动器群体进行比较，而不仅仅是与可以计算QoS度量的“不完美”驱动器的子集进行比较。这里隐含的是，偏好是尽可能广泛地基于内部数据恢复的计数。换句话讲，优选的是利用反映由驱动器执行的所有数据恢复的计数器，而不仅仅是直接在满足主机发起的IO时执行的数据恢复。

同样，当QoS度量以分子中的参数0001h计算(每个错误恢复递增一次)时，QoS度量正在测量“软错误率”。这本身被认为是有用的，但并非所有软错误都有同样担心。驱动器必须使用高度参与的数据恢复过程越频繁，则对平均主机可见延迟的影响越大。此外，频繁使用高度参与的数据恢复程序意味着增加了在不久的将来驱动器将根本无法恢复数据的可能性，从而导致硬错误。因此，优选的是利用以可变量递增的计数器，该可变量与所利用的每个错误恢复程序的延迟效应成比例。

为了减少上述考虑因素的影响，根据一个实施方案，可计算一组QoS统计值，其包含参数0004h(其很少为零，即使在参数0001h为零时)而不是参数0001h(实验显示其在10％至15％的受试驱动器中为零)。

此外，参数0004h在每个IO的错误恢复过程期间递增多次，即，针对数据恢复步骤的每次调用递增一次。

为了使用参数0004h来形成QoS(读取)统计值，公式被修改为：

(第3页参数0005h-第3页参数0001h)/第3页参数0005h＝

＝((1×10¹²)-3)/(1×10¹²)＝

99.9999999997％。

然后根据一个实施方案，对应的QoS度量将被计算为：

QoS(读取)＝-log10(第3页参数0004h/第3页参数0005h)＝

QoS(读取)＝-log10(176/(1×10¹²))＝

9.75。

存储***的子***中的QoS监测

根据一个实施方案，QoS度量的替代部署策略是将监视代理/过程嵌入数据存储***壳体监视子***中，这将监测驱动器队列的QoS统计值的责任转移到壳体而不是外部主机，并且其中QoS的驱动器模型特定知识封装在单个存储供应商提供的子***中。因此，无论它们所驻留的主机和服务器的状态如何，监视代理都将是存在的和活动的。然而，此类具体实施将限制***壳体监测和比较本地驱动器的QoS行为，并且在大型部署中，有必要升级多个***壳体以修改QoS监测逻辑的行为。

通过在典型具体实施中可用的受限操作***(OS)和计算环境，将QoS计算和评估过程嵌入到存储***壳体中变得更加复杂。具体地讲，典型的存储***环境在JBOD(“仅一串磁盘”或“仅一串驱动器”)的情况下仅具有SAS(串行附接SCSI)扩展器，或者在JBOF(“仅一串闪存”)的情况下仅具有PCIe(***部件快速互连)开关芯片。此类限制对于QoS监测代理的实现具有若干关键影响，例如，不存在标准OS(例如，Linux)和相关联的现成主机通信工具，不存在标准文件***(例如，Ext4)，这意味着由用于获取QoS前体的操作读取的数据需要适配到RAM/DRAM的专用区域中，并且不存在对浮点算术操作的硬件支持。进一步关于浮点问题，通常可以编译和链接使用浮点/双类型并调用log()函数的代码，但是在运行时，所有这些操作将捕捉为未实现的指令并且由浮点库使用整数算术(例如，与浮点算术的“直接”处理相反)来仿真。这可以大大增加与计算和比较QoS度量值相关联的执行时间，并且如果浮点仿真库尚未被固件使用，则可以极大地增加固件图像大小。

根据一个实施方案，QoS度量的另选具体实施避免了模拟浮点算术的需要。与计算在没有自主纠错的情况下传输的字节的平均百分比(即，表示为基于数量的浮点值)相反，寻求避免使用直接(例如，内部或积分)浮点算术能力可另选地计算在没有自主纠错的情况下传输的字节的平均数(例如，表示为基于二次方的整数值)。

仅使用整数算术的QoS度量的公式的一般表达式如下：

QoS＝处理的字节数/校正的可能有延迟的错误。

例如，如果日志感测页面3“读取错误计数器”报告：

参数0001h：校正的可能有延迟的错误：3；

参数0004h：处理的校正算法的总时间：176；

参数0005h：处理的总字节：1TB(1×10¹²)；

然后，使用整数除法(丢弃任何余数)如下计算在没有自主纠错的情况下传输的字节的平均数：

第3页参数0005h/第3页参数0001h＝

＝(1×10**12)/3＝

333,333,333,333。

然后通过确定所得的除数的最高有效位(MSB)的位置来计算对应的QoS度量：

333,333,333,333＝4D.9C37.0555h；

最高设置位＝38；

QoS＝38(例如，在没有自主纠错的情况下传输平均2³⁸字节)。

与浮点具体实施一样，整数具体实施适于计算总共六个不同QoS度量：三个操作域(读取、写入、验证)中的每一个的两个QoS度量(“可能有延迟”、“处理的总时间”)。然而，直接比较基于浮点和整数计算方法的值是不可行的。此外，与QoS的浮点实现一样，度量的整数实现的精确值与度量相对于对等驱动器的比较以及随时间段(诸如前一天、一周、一个月等)观察到的值的趋势不太相关。此外，与QoS的浮点实现一样，在驱动器表现出“完美”QoS的情况下，应考虑提供来计算任意值，并且当被考虑的驱动器具有与其对等驱动器的池类似的负载特性时，度量是最标准的。

现在一般来讲，QoS度量适用于任何环境，其中可以确定存储设备正在多频繁地执行导致主机可见延迟的重试，以便满足所请求的工作负载。例如，预期并认为合理的是，SSD可被配置为提供类似的前体，该前体将使得能够计算QoS度量值(或者，如果基于每个管芯提供，则提供如FRPH的值)，如本文所述。

关于日志感测日志计数器而不是SMART参数(有时称为属性)的使用，尽管SMART框架本身通常支持所有存储设备类型(HDD/SSD)和所有存储设备协议类型(SAS/SATA(串行ATA或串行高级技术附件)/NVMe(非易失性快速存储器))，但在任何特定存储设备的具体实施中支持的一组SMART参数是供应商唯一的并且依赖于具体实施。就一些企业级SAS HDD而言，可通过SMART或日志感测方法访问用于计算QoS的参数，并且因此具体设想了SMART参数的实现和使用以计算QoS值。然而，读取SMART参数的主机动作极可能导致或可以导致驱动器收集和返回与QoS计算无关的许多无关参数。因此，根据一个实施方案，优选的是，经由日志感测(而不是SMART)收集到QoS公式的输入较不具有侵扰性，因为日志感测操作返回更小的一组参数。类似地，虽然日志感测具体实施当前直接适用于SAS(SCSI)驱动器，但设想并认为合理的是，期望将SATA和/或NVMe存储设备以及尚未知道的其他类型的未来存储设备配置用于支持计算QoS度量所需的类似能力，如本文所述。

增量QoS度量

默认情况下，由日志感测页面报告的参数是基于设备寿命的，因此直接QoS度量也是基于设备寿命的。然而，根据一个实施方案，可以通过将公式应用于在不同时间捕获的日志感测参数值对之间的差值来计算增强QoS度量。这可在任意时间间隔内执行，但一般来讲，认为在一天至一周范围内的间隔可能与频繁使用的驱动器开始显示出降低或恶化的QoS行为的可能速率一致。例如，如果在不同时间捕获日志感测参数0001h和0005h(来自3个域中的任一个：读取、写入、验证)的样本，则主机可使用以下公式来计算增强QoS度量。需注意，与日志感测参数0004h和0005h一起使用的类似公式同样有效。

增量QoS＝-log10((参数0001h(N)-参数0001(N-1))/

(参数0005h(N)-参数0005h(N-1))

确定QoS度量通过/失败阈值

根据一个实施方案，优选地在相对于设备填充的基础上而不是在绝对基础上执行QoS度量的通过/失败阈值的确定。需注意，在相对健康的驱动器中需要DRP校正的错误往往以不频繁的群集模式而不是以恒定速率发生。QoS度量的使用被认为在诸如但不限于RAID(独立磁盘或驱动器冗余阵列)或擦除编码的环境中特别有效，其中各种关联驱动器全部具有大致相同的使用年限(如通过加电时间所测量的)并且经受相当的工作负载。也就是说，优选的是，不比较不同使用年限的驱动器的QoS得分，因为具有低字节数的相对未使用(或“年轻”)驱动器上的单个DRP恢复将改变QoS度量得分超过在相对更多使用(或“旧”)驱动器上的QoS度量得分。此外，优选的是不在运行显著不同的工作负载的驱动器之间比较QoS得分，因为仅在驱动器访问介质的易错磁头或区域的情况下才会遇到需要DRP恢复的错误。此外，建立QoS度量的绝对阈值的任何尝试将需要考虑驱动器外壳的热特性和振动特性。

QoS度量的驱动器监视

数据存储设备通常保持计算QoS度量所必需的统计值，并且它们周期性地记录这些寿命统计值。如果主机能够获取寿命统计值的时间序列快照，则可针对各种时间范围计算一系列寿命和增量QoS度量。

根据一个实施方案，驱动器也可以被配置为提供日志感测页2、页3和页5计数器的变体，其中，该变体提供参数值集合的列表，在HDD的情况下，每个集合显示应用于每个驱动器磁头的计数器。这将允许主机计算磁头特定QoS度量，并且将允许主机计算每个磁头的FRPH度量而无需查询E6日志。

识别性能不佳的数据存储设备的方法

图5是根据一个实施方案的示出识别性能不佳的数据存储设备的方法的流程图。图5的过程或流程可被实现为作为存储在一个或多个存储器单元中的一个或多个指令序列来执行，并且当由一个或多个处理器执行时，使得该过程执行。例如，存储在一个或多个存储器单元(例如，控制器固件固有的ROM)中的指令序列(例如，体现在图3的***控制器312的固件中，或者体现在图1A的硬盘控制器和/或HDD 100的SOC的固件中，或者体现在图1B的SSD 152的控制器162的固件中的可靠性引擎314)，并且该指令序列当由一个或多个处理器(例如，图3的***控制器312的处理器315，或构成图1A的硬盘控制器和/或HDD 100的SOC的处理器或集成在该硬盘控制器和/或该SOC内的处理器，或构成图1B的SSD 152的控制器162的处理器或集成在该控制器内的处理器)执行时，可导致图5所示过程的执行。

在框502处，从多个数据存储设备(DSD)中的每个数据存储设备检索相应的一组SCSI(小型计算机***接口)日志页面。例如，数据存储***200(图2和图3)的***控制器312(图3)从多个DSD 304a-304n(图3)中的一个或多个的QoS模块318(图3)或与该QoS模块结合以检索SCSI日志感测计数器319(图3)。如所描述的，可使用日志感测命令从SCSI目标设备(例如，DSD 304a-304n)询问或轮询SCSI“日志感测”计数器(或SCSI日志页面)，其中这些日志感测计数器由行业标准诸如T10/BSR INCITS SPC(SCSI主命令)来定义。

在框504处，基于每个相应的一组SCSI日志页面，为多个DSD中的每个相应DSD确定或计算服务质量(QoS)度量的值，其中每个QoS度量表示在相应DSD不执行自主纠错的情况下处理的字节的百分比。因此，QoS度量不是由日志感测(或SMART)参数直接报告的，而是从此类子***报告的参数导出的。例如，根据一个实施方案，使用如本文其他地方所述的日志感测参数基于前述QoS公式来计算QoS值。根据一个实施方案，QoS度量值基于以下前体计数器来计算：(a)参数0001h：校正的可能有延迟的错误或(b)参数0004h：校正算法处理的总时间，以及(c)参数0005h：被处理的总字节。此外，根据相关实施方案，QoS度量值基于来自读取域、写入域和验证操作域的域来计算。更进一步地，根据一个实施方案，对于非限制性示例，QoS度量值基于小于设备寿命的预先确定的时间段来计算，诸如在一天到一周的范围内的时间段。

在框506处，确定每个DSD的QoS值是否达到(例如，满足或超过)预先确定的QoS阈值。例如，可以将每个QoS值与对应于数据存储***(例如，图3的数据存储***200)的DSD群体(例如，图3的DSD 304a-304n)的中值、平均值或一些其他统计量度的特定百分位数或标准偏差进行比较。因此，根据一个实施方案，给定驱动器QoS度量不一定针对静态通过/失败阈值进行评估，而是针对关联的对等驱动器的QoS度量(以及观测到的QoS度量趋势)进行评估。

在框508处并且根据一个实施方案，响应于特定DSD QoS值达到预先确定的QoS阈值(例如，在框506处)，确定是针对特定DSD执行原位修复还是将特定DSD添加到候选DSD列表以用于进一步检查、调查或预后。例如，响应于DSD QoS值达到阈值，可以在特定DSD上或与特定DSD相关联地执行本文其他地方描述的各种原位修复操作。或者，根据一个实施方案，响应于DSD QoS值达到阈值，特定DSD可被放置在候选列表上以用于进一步的FRPH(每小时全恢复)检查或计算，如本文其他地方所述。在后一种情况下，响应于特定HDD磁头FRPH达到预先确定的FRPH阈值，然后可针对特定磁头在其中操作的特定HDD来确定原位修复。

现在一般来讲，QoS度量是测量高软错误率的主机可见效应，即，与可利用可指示未决驱动器故障的硬错误的方法相比，驱动器已遇到设备自主校正的许多错误。本文所述的实施方案可利用QoS度量来识别/移除相对于对等驱动器已经引起位于其上的数据集和关联的对等驱动器的即时性能问题(例如，延迟)的驱动器，而不是严格地预测未来的数据丢失和/或驱动器故障。利用QoS度量，可基于该驱动器的趋势分析，而且还基于QoS度量相对于关联的对等驱动器的值来识别性能不佳的驱动器。

QoS度量的主机监测

一般来讲，表现出QoS的较低对等驱动器值并且还在最近监测周期(例如，一周)内表现出QoS的大幅下降的HDD是包含表现出边缘的或不可接受的FRPH值的磁头的最可能的驱动器。根据一个实施方案，示出了用于在***级部署中提供关联的驱动器池中QoS的有效监测的过程的示例性过程如下。

图6是根据一个实施方案的示出识别性能不佳的数据存储设备的方法的流程图。图6的过程或流程可被实现为作为存储在一个或多个存储器单元中的一个或多个指令序列来执行，并且当由一个或多个处理器执行时，使得该过程执行。例如，存储在一个或多个存储器单元(例如，控制器固件固有的ROM)中并且当由一个或多个处理器(例如，图3的***控制器312的处理器315)执行时可使得执行图6所示的过程的指令序列(例如，体现在图3的***控制器312的固件中的可靠性引擎314)。根据实施方案，图6的过程可应用于构成一体(单个)数据存储***的多个DSD，或者图6的过程可应用于构成多个数据存储***的多个DSD(例如，多***部署)。

在框602处，周期性地轮询用于构成数据存储***的多个关联的数据存储设备(DSD)的一组错误计数器。例如，一天一次，从处于“在线”状态的所有DSD轮询日志感测页面3，这将在存储***部署中为每个DSD产生日志感测页面参数数据的唯一样本。例如，数据存储***200(图2和图3)的***控制器312(图3)从多个DSD 304a-304n(图3)中的一个或多个的QoS模块318(图3)或与该QoS模块结合以轮询、捕获、询问、检索SCSI日志感测计数器319(图3)。如所描述的，可使用日志感测命令从SCSI目标设备(例如，DSD 304a-304n)轮询SCSI“日志感测”计数器(或SCSI日志页面)，其中这些日志感测计数器由行业标准诸如T10/BSRINCITS SPC(SCSI主命令)来定义。

在框604处，基于错误计数器，为多个DSD中的每个相应DSD确定寿命服务质量(QoS)度量的值，其中每个寿命QoS(读取)度量基于在每个相应DSD不执行自主纠错的情况下，在相应DSD的寿命内处理的字节的平均百分比。例如，根据一个实施方案，使用如本文其他地方所述的日志感测参数基于前述QoS公式来计算寿命QoS值。

在框606处，针对轮询周期记录每个寿命QoS度量值。例如，每个寿命QoS度量值(在框604处计算)可连同轮询的时间/日期和驱动器序列号一起记录在数据库(例如，与图3的可靠性引擎314和/或QoS模块318相关联、可访问和/或在其管理下的数据对象存储构造，并且其以技术人员已知的方式构造)中。

进一步继续该过程的实施方案，在框608处，识别在最近轮询周期期间表现出其最低寿命QoS值的多个DSD的特定百分比/百分位数子集。例如，每天一次，一旦QoS的“当前”和“星期旧”样本都可用，就查询数据库以识别在最近轮询周期期间表现出最低寿命QoS(读取)度量的驱动器的“最差子集”(对于非限制性示例，可能为1％)。

在框610处，对于其最近寿命QoS值比DSD子集内具有最高QoS值的DSD的最近寿命QoS值低一个单位以上的DSD的子集的每个DSD，将每个此类DSD添加到候选DSD列表中。例如，对于其最近寿命QoS(读取)得分比“最差子集”组内的最高得分驱动器的得分低一个以上单位的每个驱动器，将该驱动器添加到候选驱动器列表中以进行FRPH检查。

另外，在框612处，对于自从计算特定先前寿命QoS值以来其最近寿命QoS值已下降多于一个单位的DSD的子集的每个DSD，将每个此类DSD添加到候选DSD列表。例如，在“最差子集”组内，对于自从例如一周前捕获的度量值样本以来，其寿命QoS(读取)得分已下降多于一个单位的每个驱动器，将该驱动器添加到候选驱动器列表中以进行FRPH检查。

在框614处，对于来自未被配置用于计算对应FRPH值的候选DSD列表中的每个DSD，确定是修复还是停用每个此类DSD。例如，在缺乏检索FRPH度量的能力的***(例如，一组SSD)中，主机可以修复或停用该驱动器，前提条件是这样做不会不适当地损害***数据完整性或安全性。

进一步继续该过程的实施方案，在框616处，对于来自被配置用于计算对应FRPH值的候选DSD列表中的每个DSD，从候选DSD列表中移除在小于轮询周期的预先确定的时间段内通过FRPH检查的任何DSD。例如，检查用于FRPH检查的候选者列表，并且如果列表中的任何驱动器已经通过FRPH检查，例如，在最后一天内，则移除列表中的该驱动器。

在框618处，对于保留在候选DSD列表上的每个DSD，计算每个此类DSD的每个相应读写磁头的FRPH值。例如，对于保留在列表上用于FRPH检查的所有驱动器，根据本文别处更详细描述的过程，获取E6日志并计算每个磁头的FRPH度量。根据一个实施方案，如果任何驱动器的最差磁头的FRPH评分超过1.0，则修复或停用该驱动器，前提条件是这样做不会不当地损害***数据完整性或安全性。

现在一般来讲，本文在QoS度量的上下文中描述的内容提供了一种非侵入式方法，以识别表现出比其对等驱动器更高的平均延迟的驱动器，虽然在存储行业内已知的其他方法集中于减少过多的尾延迟、聚合不相关的延迟源的测量、或依赖于驱动器本身来发信号通知其不再健康(例如，SMART)。QoS度量提供了使存储***周期性地从所有驱动器获取E6日志以检查它们中的任一个是否表现出不可接受的FRPH度量的替代解决方案，该FRPH度量可能会消耗非微不足道的资源，包括磁盘IO、总线带宽、CPU内核/周期和存储器带宽，所有这些都是昂贵的并且在数据存储***中被认为是宝贵的。此外，QoS度量背后的概念对于SCSI或旋转介质磁盘驱动器不是唯一的。相反，QoS是反映任何类型的存储设备在主机读取、写入或验证操作期间如何努力来保持正在处理的数据的完整性的简单测量。

硬盘驱动器配置

如所讨论的，实施方案可在采用多个数据存储设备(DSD)诸如HDD的数据存储***的上下文中使用。因此，根据一个实施方案，图1A中显示了示出HDD 100的平面图以示出示例性操作组件。

图1A示出了包括滑块110b的HDD 100的部件的功能布置，滑块110b包括磁性读写磁头110a。滑块110b和磁头110a可统称为磁头滑块。HDD 100包括具有磁头滑块的至少一个磁头万向节组件(HGA)110、通常经由弯曲部附接到磁头滑块的引线悬架110c，以及附接到引线悬架110c的负载梁110d。HDD 100还包括可旋转地安装在主轴124上的至少一个记录介质120和附接到主轴124用于旋转介质120的驱动马达(不可见)。读写磁头110a(也可以称为换能器)包括写元件和读元件，用于分别写入和读取存储在HDD 100的介质120上的信息。可使用磁盘夹128将介质120或多个磁盘介质附连到主轴124。

HDD 100还包括附接到HGA 110的臂132、滑架134、包括电枢136和定子144的音圈马达(VCM)，电枢136包括附接到滑架134的音圈140，转子144包括音圈磁体(不可见)。VCM的电枢136附接到滑架134并且被配置为移动臂132和HGA 110以访问介质120的部分，它们共同安装在具有插置的枢转轴承组件152的枢轴148上。就具有多个磁盘的HDD而言，滑架134可称为“E形块”或梳齿，因为滑架被布置为承载联动的臂阵列，从而使之呈现梳齿的外观。

包括包含磁头滑块耦接至的弯曲部的磁头万向节组件(例如，HGA 110)、弯曲部耦接至的致动器臂(例如，臂132)和/或负载梁，以及致动器臂耦接至的致动器(例如，VCM)的组件可以统称为磁头堆叠组件(HSA)。然而，HSA可包括比所述的那些更多或更少的部件。例如，HSA可指还包括电互连部件的组件。一般来讲，HSA是被配置为移动磁头滑块以访问介质120的部分以进行读和写操作的组件。

进一步参考图1，包括至磁头110a的写信号和来自磁头110a的读信号的电信号(例如，到VCM的音圈140的电流)由柔性电缆组件(FCA)156(或“柔性电缆”)传输。柔性电缆156与磁头110a之间的互连件可包括臂电子(AE)模块160，该AE模块可具有读信号的板载前置放大器以及其他读通道和写通道电子部件。AE模块160可附接到滑架134，如图所示。柔性电缆156可以耦接到电连接器块164，该电连接器块164在一些配置中通过由HDD外壳168提供的电馈通提供电气连通。HDD外壳168(或“壳体底座”或“基板”或简称“底座”)与HDD盖一起为HDD 100的信息存储组件提供半密封(或气密密封，在一些配置中)的保护壳体。

其他电子部件，包括磁盘控制器和包括数字信号处理器(DSP)的伺服电子器件，向驱动马达、VCM的音圈140和HGA 110的磁头110a提供电信号。提供给驱动马达的电信号使驱动马达旋转，从而向主轴124提供扭矩，该扭矩继而传输到附连到主轴124的介质120。因此，介质120沿方向172旋转。旋转的介质120形成空气垫，该空气垫充当滑块110b的空气轴承表面(ABS)搭载于其上的空气轴承，以使得滑块110b在介质120的表面上方飞行，而不与记录信息的薄磁记录层形成接触。类似地，在利用轻于空气的气体(诸如用于非限制性示例的氦气)的HDD中，旋转的介质120形成气垫，该气垫充当滑块110b搭载于其上的气体或流体轴承。

向VCM的音圈140提供的电信号使HGA 110的磁头110a能够访问上面记录有信息的磁道176。因此，VCM的电枢136摆动经过圆弧180，这使HGA 110的磁头110a能够访问介质120上的各个磁道。信息存储在介质120上的多个径向嵌套的磁道中，这些磁道被布置在介质120上的扇区(诸如扇区184)中。相应地，每个磁道由多个扇区化磁道部分(或“磁道扇区”)诸如扇区化磁道部分188构成。每个扇区化磁道部分188可包括记录的信息和数据头，该数据头包含纠错码信息和伺服突发信号图案，诸如ABCD-伺服突发信号图案(其是识别磁道176的信息)。在访问磁道176时，HGA 110的磁头110a的读元件读取伺服突发信号图案，该伺服突发信号图案向伺服电子器件提供定位错误信号(PES)，这会控制向VCM的音圈140提供的电信号，从而使磁头110a能够跟随磁道176。在找到磁道176并识别特定的扇区化磁道部分188时，磁头110a或者从磁道176读取信息或者根据磁盘控制器从外部代理(例如计算机***的微处理器)接收的指令将信息写入磁道176。

HDD的电子架构包括用于执行其各自的HDD操作功能的多个电子部件，诸如硬盘控制器(“HDC”)、接口控制器、臂电子模块、数据通道、马达驱动器、伺服处理器、缓冲存储器等。两个或更多个此类部件可以组合在称为“片上***”(“SOC”)的单个集成电路板上。此类电子部件中的若干个(如果不是全部的话)通常布置在印刷电路板上，该印刷电路板耦接到HDD的底侧，诸如耦接到HDD外壳168。

本文参考硬盘驱动器，诸如参考图1所示和所述的HDD 100，可以包括有时被称为“混合驱动器”的信息存储设备。混合驱动器通常指的是具有常规HDD(参见例如HDD 100)与使用非易失性存储器(诸如闪存或其他固态(例如，集成电路)存储器)的固态存储设备(SSD)(其为电可擦除和可编程的)组合的功能的存储设备。由于不同类型的存储介质的操作、管理和控制通常不同，因此混合驱动器的固态部分可包括其自身对应的控制器功能，该控制器功能可与HDD功能一起集成到单个控制器中。混合驱动器可被构建和配置为以多种方式操作并利用固态部分，诸如作为非限制性示例，将固态存储器用作高速缓存存储器，用于存储频繁访问的数据，用于存储I/O密集数据等。另外，混合驱动器可以被构建和配置为基本上作为单个壳体中的两个存储设备，即常规的HDD和SSD，具有用于主机连接的一个或多个接口。

固态驱动器配置

如所讨论的，实施方案可在采用多个数据存储设备(DSD)诸如SSD的数据存储***的上下文中使用。因此，图1B是示出可以实现本发明的实施方案的示例性操作上下文的框图。图1B示出了通用SSD架构150，其中SSD 152通过主通信接口156与主机154通信地耦接。实施方案不限于如图1B所描绘的配置，相反，实施方案可以利用除图1B所示之外的SSD配置来实现。例如，实施方案可被实现为在依赖于用于写入和读取数据的非易失性存储器存储部件的其他环境中操作。

主机154广义地表示对一个或多个存储器设备进行数据I/O请求或调用等的任何类型的计算硬件、软件或固件(或前述的任何组合)。例如，主机154可以是在计算机、平板电脑、移动电话或通常包含存储器或与存储器交互的任何类型的计算设备上执行的操作***，诸如主机350(图3)。将主机154耦接到SSD 152的主接口156可以是例如存储***的内部总线或通信电缆或无线通信链路等。

图1B所示的示例性SSD 152包括接口160、控制器162(例如，其中具有固件逻辑的控制器)、寻址164功能块、数据缓冲器高速缓存166以及一个或多个非易失性存储器部件170a、170b-170n。

接口160是部件即SSD 152与主机154之间在该上下文中的交互点，并且在硬件和软件两者的层级上均适用。这允许部件经由输入/输出(IO)***和相关联的协议与其他部件进行通信。硬件接口通常由接口处的机械信号、电信号和逻辑信号以及用于对它们进行排序的协议来描述。通用和标准接口的一些非限制性示例包括SCSI(小型计算机***接口)、SAS(串行附接SCSI)和SATA(串行ATA)。

SSD 152包括控制器162，该控制器将把非易失性存储器部件(例如，NAND闪存)桥接到主机(诸如非易失性存储器170a、170b、170n)的电子器件结合到主机154。控制器通常是执行固件级代码的嵌入式处理器，并且是SSD性能的重要因素。

控制器162经由寻址164功能块与非易失性存储器170a、170b、170n进行交互。寻址164功能用于例如管理从主机154到SSD 152上(即SSD 152的非易失性存储器170a、170b、170n上)的对应物理块地址的逻辑块地址(LBA)之间的映射。因为非易失性存储器页面和主机扇区的大小不同，所以SSD必须构建和维护使其能够在将数据写入扇区或从扇区读取数据的主机与实际放置该数据的物理非易失性存储器页面之间转换的数据结构。可为SSD的易失性存储器172中的会话构建和维护该表结构或“映射”，诸如DRAM或控制器162和寻址164可访问的一些其他本地易失性存储器部件。另选地，可以在SSD的非易失性存储器诸如非易失性存储器170a、170b-170n中的会话上更持久地保持表结构。

除非易失性存储器170a、170b-170n之外，寻址164还与数据缓冲器高速缓存166交互。SSD 152的数据缓冲器高速缓存166通常使用DRAM作为高速缓存，类似于硬盘驱动器中的高速缓存。数据缓冲器高速缓存166用作向和从非易失性存储器部件传输数据的缓冲器或分级区域，并且用作高速缓存以加快对高速缓存数据的未来请求。数据缓冲器高速缓存166通常用易失性存储器来实现，因此存储在其中的数据不会永久性地存储在高速缓存中，即，数据不是持久性的。

最后，SSD 152包括一个或多个非易失性存储器170a、170b-170n部件。对于非限制性示例，非易失性存储器部件170a、170b-170n可被实现为闪存存储器(例如，NAND或NOR闪存)或现在或将来可用的其他类型的固态存储器。非易失性存储器170a、170b-170n部件是数据持续存储在其上的实际存储器电子部件。SSD 152的非易失性存储器170a、170b-170n部件可被认为是硬盘驱动器(HDD)存储设备中的硬盘的模拟。

此外，本文对数据存储设备的引用可涵盖多介质存储设备(或“多介质设备”，其有时可被称为“多层设备”或“混合驱动器”)。多介质存储设备通常指的是具有常规HDD(参见例如HDD 100)与使用非易失性存储器(诸如闪存或其他固态(例如，集成电路)存储器)的SSD(例如，参见SSD 150)(其为电可擦除和可编程的)组合的功能的存储设备。由于不同类型的存储介质的操作、管理和控制通常不同，因此混合驱动器的固态部分可包括其自身对应的控制器功能，该控制器功能可与HDD功能一起集成到单个控制器中。多介质存储设备可被构建和配置为以多种方式操作并利用固态部分，诸如作为非限制性示例，将固态存储器用作高速缓存存储器，用于存储频繁访问的数据，用于存储I/O密集数据，用于存储对应于有效载荷数据的元数据(例如，用于辅助解码有效载荷数据)等。另外，多介质存储设备可以被构建和配置为基本上作为单个壳体中的两个存储设备，即常规的HDD和SSD，具有用于主机连接的一个或多个接口。

扩展和另选的替代方案

在前述说明中，已经参照大量的具体细节描述了本发明的实施方案，这些细节可根据不同的具体实施而变化。因此，可以在不脱离实施方案较宽的实质和范围的情况下对其进行各种修改和改变。因此，本发明以及申请人旨在成为本发明的唯一且排他性的指示物的是由本专利申请以此类权利要求发出的具体形式发出的一组权利要求，包括任何后续的更正。本文明确阐述的对包含在这些权利要求中的术语的任何定义应当决定如权利要求中使用的这些术语的含义。从而，未在权利要求中明确引述的限制、元件、特性、特征、优点或属性不应以任何方式限制此权利要求的范围。因此，本说明书和附图被认为是示例性意义的而不是限制性意义的。

此外，在该描述中，某些过程步骤可按特定顺序示出，并且字母和字母数字标签可用于识别某些步骤。除非在说明书中明确指明，否则实施方案不一定限于执行此类步骤的任何特定顺序。具体地讲，这些标号仅用于方便步骤的识别，并非旨在指定或要求执行此类步骤的特定顺序。

Claims (20)

1.一种用于识别性能不佳的数据存储设备(DSD)的方法，所述方法包括：

从多个数据存储设备(DSD)中的每一个数据存储设备检索相应的一组错误日志页面；

基于每个相应的一组日志页面，确定所述多个DSD中的每个相应DSD的服务质量(QoS)度量的值，其中每个QoS值表示在所述相应DSD不执行自主纠错的情况下被处理的字节的百分比；

确定每个DSD QoS值是否达到预先确定的QoS阈值；以及

响应于特定DSD QoS值达到所述预先确定的QoS阈值，确定是针对所述特定DSD执行原位修复还是将所述特定DSD添加到候选DSD列表以供进一步检查。

2.根据权利要求1所述的方法，其中：

检索所述一组错误日志页面包括检索一组SCSI(小型计算机***接口)日志感测计数器；并且

确定所述QoS度量的所述值包括基于来自由以下项组成的参数组的至少两个参数来进行确定：(1)参数0001h：校正的可能有延迟的错误，(2)参数0004h：校正算法处理的总时间，和(3)参数0005h：被处理的总字节。

3.根据权利要求2所述的方法，其中确定所述QoS度量的所述值包括基于来自由读取域、写入域和验证操作域组成的一组域中的一个域来进行确定。

4.根据权利要求1所述的方法，其中检索所述一组错误日志页面包括检索一组SMART(自我监测、分析与报告技术)参数，所述一组SMART参数指示(i)校正的总错误数量，(ii)校正算法调用的数量，和(iii)被处理的总字节数。

5.根据权利要求1所述的方法，其中确定所述QoS度量的所述值包括确定与小于每个相应DSD的寿命的预先确定的时间段对应的所述QoS度量的所述值。

6.根据权利要求1所述的方法，其中确定特定DSD QoS值是否达到预先确定的QoS阈值包括将所述特定DSD QoS与跟所述多个DSD对应的QoS值的统计量度进行比较。

7.根据权利要求6所述的方法，其中所述多个DSD关联在DSD的RAID(独立磁盘或驱动器冗余阵列)分组中。

8.根据权利要求6所述的方法，其中所述多个DSD关联在应用于所述多个DSD的擦除编码范式中。

9.根据权利要求1所述的方法，其中确定是否将所述特定DSD添加到所述列表包括确定是否将所述特定DSD添加到候选DSD列表以用于进一步的每小时全恢复(FRPH)检查，包括：

从作为特定硬盘驱动器(HDD)的所述特定DSD来检索恢复日志；以及

基于所述恢复日志，确定所述特定HDD的每个相应读写磁头的FRPH度量的值，包括：

对所述磁头在特定时长内在由所述磁头执行的所有恢复步骤上花费的时间量求和，包括将全恢复表征为对应于所述磁头在一个或多个恢复步骤上花费的预先确定的时长，

确定在所述特定时长内的相等数量的全恢复，以及

基于所述全恢复的数量和所述特定时长，确定所述磁头的所述FRPH度量的所述值。

10.根据权利要求9所述的方法，所述方法还包括：

响应于特定磁头FRPH度量的值达到预先确定的FRPH阈值，确定针对所述特定磁头在其中运行的所述特定HDD的原位修复。

11.一种用于从构成数据存储***的多个关联的数据存储设备(DSD)中识别性能不佳的DSD的方法，所述方法包括：

周期性地轮询所述多个DSD的一组错误计数器；

基于所述错误计数器，确定多个DSD中的每个相应DSD的寿命服务质量(QoS)度量的值，其中每个寿命QoS值基于在每个相应DSD不执行自主纠错的情况下在所述相应DSD的寿命内被处理的字节的平均百分比；以及

记录针对轮询周期的每个寿命QoS度量值。

12.根据权利要求11所述的方法，所述方法还包括：

识别在最近轮询周期期间所述多个DSD中的表现出最低寿命QoS值的特定百分比子集；

对于所述DSD子集中的最近寿命QoS值比所述子集内具有最高寿命QoS值的DSD的最近寿命QoS值低一个单位以上的每个DSD，将每个此类DSD添加到候选DSD列表；

对于自计算特定先前寿命QoS值以来所述DSD子集中的最近寿命QoS值已下降多于一个单位的每个DSD，将每个此类DSD添加到所述候选DSD列表；以及

对于所述候选DSD列表上未被配置用于计算对应的每小时全恢复(FRPH)值的每个DSD，确定是修复还是停用每个此类DSD。

13.根据权利要求12所述的方法，所述方法还包括：

对于所述候选DSD列表上被配置用于计算所述FRPH值的每个DSD，从所述候选DSD列表中移除在小于所述轮询周期的预先确定的时间段内已经通过FRPH检查的任何DSD；以及

对于保留在所述候选DSD列表上的每个DSD，计算每个此类DSD的每个相应读写磁头的所述FRPH值。

14.根据权利要求11所述的方法，其中所述多个DSD构成单个数据存储***。

15.根据权利要求11所述的方法，其中所述多个DSD构成多个数据存储***。

16.一种数据存储***，包括：

***控制器电路，所述***控制器电路包括存储器和一个或多个处理器，并且实施一个或多个指令序列，所述一个或多个指令序列在由所述一个或多个处理器执行时，使得执行以下操作：

从多个数据存储设备(DSD)中的每个数据存储设备检索相应的一组错误日志页面；

基于每个相应的一组错误日志页面，确定所述多个DSD中的每个相应DSD的服务质量(QoS)度量的值，其中每个QoS值表示在所述相应DSD不执行自主纠错的情况下被处理的字节的百分比；

确定每个DSD QoS值是否达到预先确定的QoS阈值；以及

响应于特定DSD QoS值达到所述预先确定的QoS阈值，确定是针对所述特定DSD执行原位修复还是将所述特定DSD添加到候选DSD列表以供进一步的每小时全恢复(FRPH)检查。

17.根据权利要求16所述的数据存储***，其中：

检索所述一组错误日志页面包括检索一组SCSI(小型计算机***接口)日志感测计数器；并且

确定所述QoS度量的所述值包括基于来自由以下项组成的参数组的至少两个参数来进行确定：(1)参数0001h：校正的可能有延迟的错误，(2)参数0004h：校正算法处理的总时间，和(3)参数0005h：被处理的总字节。

18.根据权利要求16所述的数据存储***，其中确定特定DSD QoS值是否达到预先确定的QoS阈值包括将所述特定DSD QoS与跟所述多个DSD对应的QoS值的统计量度进行比较。

19.根据权利要求16所述的数据存储***，其中所述一个或多个处理器未被配置为直接处理浮点算术操作。

20.一种数据存储***，包括：

多个数据存储设备(DSD)；

用于从多个数据存储设备(DSD)中的每个数据存储设备检索相应的一组SCSI(小型计算机***接口)日志页面的装置；

用于基于每个相应的一组SCSI日志页面来确定针对所述多个DSD中的每个相应DSD的服务质量(QoS)度量的值的装置，其中每个QoS值表示在所述相应DSD不执行自主纠错的情况下被处理的字节的百分比；

用于确定每个DSD QoS值是否达到预先确定的QoS阈值的装置；以及

用于以下操作的装置：响应于特定DSD QoS值达到所述预先确定的QoS阈值，确定是针对所述特定DSD执行原位修复还是将所述特定DSD添加到候选DSD列表以供进一步的每小时全恢复(FRPH)检查。

Images