存储设备、程序和信息处理方法与流程

本发明涉及一种存储设备、程序和信息处理方法。具体的，本发明涉及一种消除具有相同内容的数据的重复存储的存储设备，并且还涉及程序和信息处理方法。

背景技术：

一种具有消除重复存储功能的存储设备被公知为用于有效率地处置大量数据的技术。

例如，在执行如上面提到的去重(deduplication)的存储系统中，将新数据添加至存储区域的末尾。因此，在稍后检索数据时，可能需要操作磁盘庞大次数以便检索到分散在整个存储设备中的块数据。

例如，在专利文献1中描述了一种用于处置上述问题的技术。专利文献1描述了一种存储设备，该存储设备具有多个存储介质、缓存内存和控制部，该控制部控制向存储介质输入/从存储介质输出数据。根据专利文献1，控制部向主机设备提供第一和第二存储区域，该第一和第二存储区域由多个存储介质的存储区域构成并且具有相同的性能特性。具体的，控制部将作为经去重数据流的第一数据流存储到第一存储区域中，并且在将第一数据流被去重之前基于数据流来生成的第二数据流存储到由第二存储区域构成的物理区域的连续区域中。根据专利文献1，这样的构成使得能够将经去重的第一数据串存储到第一存储区域中，并且将第二数据串存储到由第二存储区域构成的物理区域的连续区域中。因此，根据专利文献1，变得有可能对存储在连续区域中的数据而不是经去重的和碎片化的数据进行分级，并且变得有可能提高存取性能。

进一步地，例如，在专利文献2中也描述了一种处置上述问题的技术。专利文献2描述了一种存储设备，该存储设备具有数据划分装置、块检测装置和数据写入装置。根据专利文献2，块检测装置检测共同率，该共同率表示在经划分的块数据当中写入目标数据的给定范围进行构成的多个连续块数据与已经顺序地存储在存储设备中的给定范围中的多个块数据之间的共同部分的比率。进一步地，数据写入设备根据由块检测装置检测到的共同率来将经划分的块数据重新存储到存储设备中。根据专利文献2，这样的构成使得能够进行控制以便仅在例如共同率小于给定阈值时将块数据重新写入存储设备。因此，根据专利文献2，有可能抑制块数据在存储设备内的整个存储区域中的分散。因此，变得有可能抑制检索性能的降低。

参考文献

专利文献

专利文献1：WO2014-136183

专利文献2：JP 2013-541055

技术实现要素：

技术问题

然而，在专利文献1中描述的技术的情况下，不仅需要保留存储经去重的第一数据流的第一存储区域，而且还需要保留第二存储区域。因此，存在存储设备的容量的消耗问题。此外，在上面描述的技术的情况下，存在难以应对在一系列检索过程过程期间由相同块的两次或者更多次出现所导致的检索性能的降低问题。换言之，存在以下问题：当再次需要将块数据加载到缓存中时，可能已经将该数据从缓存中逐出，并且可能需要再次从磁盘检索该数据。

因此，仍然难以抑制在具有消除重复存储功能的存储设备中的检索性能的降低。

因此，本发明的目的是提供一种存储设备，该存储设备可以解决难以抑制在具有消除重复存储功能的存储设备中的检索性能的降低的上述问题。

技术方案

为了实现该目的，作为本发明的一个方面，一种存储设备包括：

数据存储部，该数据存储部存储经去重的块数据；

临时数据存储部，该临时数据存储部临时存储从数据存储部获取的块数据；

数据检索控制部，该数据检索控制部检索由数据存储部存储的块数据，将该块数据存储到临时数据存储部中，并且从该临时数据存储部检索块数据；以及

临时数据控制部，该临时数据控制部控制由临时数据存储部存储的块数据的存储状态。

存储设备还包括检索轮次信息存储部，该检索轮次信息存储部存储作为关于块数据的检索轮次的信息的检索轮次信息。

数据检索控制部使得临时数据存储部基于从检索轮次信息存储部获取的检索轮次信息来存储从数据存储部获取的块数据。

临时数据控制部基于检索轮次信息来控制在临时数据存储部中的块数据的存储状态。

进一步地，作为本发明的另一方面，一种计算机程序包括指令，该指令用于使得信息处理设备实现以下装置——该信息处理设备包括：存储去重的块数据的数据存储部；临时存储从数据存储部获取的块数据的临时数据存储部；以及存储作为关于块数据的检索轮次的信息的检索轮次信息的检索轮次信息存储部：

数据检索控制装置，该数据检索控制装置用于检索由数据存储部存储的块数据，将该块数据存储到临时数据存储部中，并且从该临时数据存储部检索块数据；以及

临时数据控制装置，该临时数据控制装置用于控制由临时数据存储部存储的块数据的存储状态。

数据检索控制装置使得临时数据存储部基于从检索轮次信息存储部获取的检索轮次信息来存储从数据存储部获取的块数据。

临时数据控制装置基于检索轮次信息来控制在临时数据存储部中的块数据的存储状态。

进一步地，作为本发明的另一方面，一种信息处理方法包括：

获取作为关于块数据的检索轮次的信息的检索轮次信息；

使得临时存储设备基于所获取的检索轮次信息来存储从存储设备获取的块数据；以及

基于检索轮次信息来控制在临时存储设备中的块数据的存储状态。

有益效果

利用上述配置，本发明可以实现可以解决难以抑制检索性能的降低问题的存储设备。

附图说明

图1是示出了包括在本发明的第一示例性实施例中的存储系统的整个系统的配置的示例的框图；

图2是示出了在本发明的第一示例性实施例中的存储系统的配置概述的示例的框图；

图3是示出了在本发明的第一示例性实施例中的存储系统的配置的示例的功能框图；

图4是用于描述由在图3中示出的磁盘设备存储的数据的示意图；

图5是用于描述由在图3中示出的缓存内存存储的数据的示意图；

图6是示出了在图5中示出的块数据轮次信息的配置的示例的示意图；

图7是示出了在图5中示出的数据信息的配置的示例的示意图；

图8是用于描述由在图3中示出的恢复管理部分执行的数据检索过程的表达的示意图；

图9是用于描述由在图3中示出的恢复管理部分执行的该数据检索过程的表达的示意图；

图10是示出了由在图3中示出的存储系统执行的检索过程的操作的流程图；

图11是示出了在本发明的第二示例性实施例中的存储系统的配置的示例的功能框图；

图12是用于描述在图11中公开的存储系统中的数据写入过程的表达的示例的解释性视图；

图13是用于描述在图11中公开的存储系统中的数据写入过程的表达的示例的解释性视图；

图14是用于描述在图11中公开的存储系统中的数据写入过程的表达的示例的解释性视图；

图15是用于描述在图11中公开的存储系统中的数据写入过程的表达的示例的解释性视图；

图16是示出了在图11中公开的存储系统中的数据写入过程的操作的示例的流程图；

图17是示出了多个相同块数据出现在与写入请求有关的一系列流数据中的示例的示意图；

图18是示出了在本发明的第三示例性实施例中的存储设备的配置的示例的框图；

图19是在本发明的第四示例性实施例中描述的研究论文中参考的示意图；

图20是在本发明的第四示例性实施例中描述的研究论文中参考的示意图；

图21是在本发明的第四示例性实施例中描述的研究论文中参考的示意图；

图22是在本发明的第四示例性实施例中描述的研究论文中参考的示意图；

图23是在本发明的第四示例性实施例中描述的研究论文中参考的示意图；

图24是在本发明的第四示例性实施例中描述的研究论文中参考的示意图；

图25是在本发明的第四示例性实施例中描述的研究论文中参考的示意图；

图26是在本发明的第四示例性实施例中描述的研究论文中参考的示意图；

图27是在本发明的第四示例性实施例中描述的研究论文中参考的示意图；

图28是在本发明的第四示例性实施例中描述的研究论文中参考的示意图；

图29是在本发明的第四示例性实施例中描述的研究论文中参考的示意图；

图30是在本发明的第四示例性实施例中描述的研究论文中参考的示意图；

图31是在本发明的第四示例性实施例中描述的研究论文中参考的示意图；

图32是在本发明的第四示例性实施例中描述的研究论文中参考的示意图；

图33是在本发明的第四示例性实施例中描述的研究论文中参考的示意图；

图34是在本发明的第四示例性实施例中描述的研究论文中参考的示意图；

图35是在本发明的第四示例性实施例中描述的研究论文中参考的示意图；

图36是在本发明的第四示例性实施例中描述的研究论文中参考的示意图；

图37是在本发明的第四示例性实施例中描述的研究论文中参考的示意图；

图38是在本发明的第四示例性实施例中描述的研究论文中参考的示意图；

图39是在本发明的第四示例性实施例中描述的研究论文中参考的示意图；

图40是在本发明的第四示例性实施例中描述的研究论文中参考的示意图；

图41是在本发明的第四示例性实施例中描述的研究论文中参考的示意图；

图42是在本发明的第四示例性实施例中描述的研究论文中参考的示意图；

图43是在本发明的第四示例性实施例中描述的研究论文中参考的示意图；

图44是在本发明的第四示例性实施例中描述的研究论文中参考的示意图；

图45是在本发明的第四示例性实施例中描述的研究论文中参考的示意图；

图46是在本发明的第四示例性实施例中描述的研究论文中参考的示意图；

图47是在本发明的第四示例性实施例中描述的研究论文中参考的示意图；

图48是在本发明的第四示例性实施例中描述的研究论文中参考的示意图；

图49是在本发明的第四示例性实施例中描述的研究论文中参考的示意图；

图50是在本发明的第四示例性实施例中描述的研究论文中参考的示意图；

图51是在本发明的第四示例性实施例中描述的研究论文中参考的示意图；

图52是在本发明的第四示例性实施例中描述的研究论文中参考的示意图；

图53是在本发明的第四示例性实施例中描述的研究论文中参考的示意图；

图54是在本发明的第四示例性实施例中描述的研究论文中参考的示意图；

图55是在本发明的第四示例性实施例中描述的研究论文中参考的示意图；

图56是在本发明的第四示例性实施例中描述的研究论文中参考的示意图；

图57是在本发明的第四示例性实施例中描述的研究论文中参考的示意图；

图58是在本发明的第四示例性实施例中描述的研究论文中参考的示意图；

图59是在本发明的第四示例性实施例中描述的研究论文中参考的示意图；

图60是在本发明的第四示例性实施例中描述的研究论文中参考的示意图；

图61是在本发明的第四示例性实施例中描述的研究论文中参考的示意图；

图62是在本发明的第四示例性实施例中描述的研究论文中参考的示意图；

图63是在本发明的第四示例性实施例中描述的研究论文中参考的示意图；

图64是在本发明的第四示例性实施例中描述的研究论文中参考的示意图；

图65是在本发明的第四示例性实施例中描述的研究论文中参考的示意图；

图66是在本发明的第四示例性实施例中描述的研究论文中参考的示意图；

图67是在本发明的第四示例性实施例中描述的研究论文中参考的示意图；

图68是在本发明的第四示例性实施例中描述的研究论文中参考的示意图。

具体实施方式

<第一示例性实施例>

将参照图1至图10来对本发明的第一示例性实施例进行描述。图1是示出了包括存储系统1的整个系统的配置的框图。图2是示出了存储系统1的概述的框图。图3是示出了存储系统1的配置的示例的功能框图。图4是用于描述由在图3中示出的磁盘设备12存储的数据的示意图。图5是用于描述由在图3中示出的缓存内存14存储的数据的示意图。图6是示出了在图5中示出的块数据轮次信息141的配置的示例的示意图。图7是示出了在图5中示出的数据信息142的配置的示例的示意图。图8和图9是用于描述由在图3中示出的恢复管理部分13执行的数据检索过程的表达(appearance)的示意图。图10是示出了由在图3中示出的存储系统1执行的检索过程的操作的流程图。

在本发明的第一示例性实施例中，将对具有去重功能并且通过有效率使用缓存内存14来抑制检索性能的降低的存储系统1进行描述。当在该示例性实施例中的存储系统1执行恢复时，存储系统1通过使用指示块数据的检索顺序的元数据来控制在缓存内存14中的块数据的存储状态，将在稍后对其进行描述。通过执行这样的控制，存储系统1可以在恢复期间依赖于由缓存内存14存储的待检索的每个块数据的下一轮次来选择应当留在缓存内存14中(从缓存内存14中删除)的块数据，将在稍后对其进行描述。因此，可以降低在重用之前删除由缓存内存14存储的块数据的风险和保持完全不必要的块数据被存储在缓存内存14中的风险，并且可以抑制检索性能的降低。

该示例性实施例示出了在稍后描述的附录中公开的存储设备等的具体示例。下面，将对存储系统1由彼此连接的多个服务器计算机配置的情况进行描述。然而，根据本发明的存储系统1不限于由多个计算机配置，并且可以由一个计算机配置。

如在图1中示出的，经由网络N将根据本发明的存储系统1与控制备份过程等的备份系统4连接。该备份系统4经由网络N来获取存储在连接至备份系统4的备份目标设备5中的备份目标数据(作为待写入的目标的数据)，并且请求存储系统1存储该数据。因此，存储系统1存储请求被存储的备份目标数据以供备份。进一步地，备份系统4向存储系统1传送给出用于数据恢复的指令的流识别符。因此，存储系统1开始进行恢复以复原由流识别符指示的文件。

如在图2中示出的，在该示例性实施例中的存储系统1采用多个服务器计算机彼此连接的配置。具体的，存储系统1包括：加速器节点2，该加速器节点2是控制存储系统1中的存储再现(reproduction)操作的服务器计算机；以及存储节点3，该存储节点3是包括存储数据的存储设备的服务器计算机。加速器节点2的数目和存储节点3的数目不限于在图2中示出的那些节点，并且可以通过连接更多的节点2和更多的节点3来配置该系统。

此外，在该示例性实施例中的存储系统1是内容可寻址存储系统，该内容可寻址存储系统划分数据并且使该数据冗余以将该数据分布并且存储到多个存储设备中，并且通过根据所存储的数据的内容设置的唯一内容地址，来指定存储数据的存储位置。

因此，可以通过使用内容地址来识别由存储系统1存储的每个块数据。具体的，基于每个块数据的内容来计算每个块数据的内容地址。例如，通过使用散列函数——诸如160位SHA1来计算内容地址。

下面，将假设存储系统1是一个系统来对存储系统1的配置和功能进行描述。换言之，可以将下面要描述的存储系统1的配置和功能包括在加速器节点2或者存储节点3中。同时，存储系统1不必限于包括如在图2中示出的加速器节点2和存储节点3，并且可以具有任何配置。例如，存储系统1可以由一个计算机配置。除此之外，存储系统1不限于内容可寻址存储系统，并且可以是任何存储系统——只要其具有去重功能。

图3示出了在该示例性实施例中的存储系统1的配置。存储系统1由服务器计算机配置并且包括执行给定的运算过程的运算设备(在附图中未示出)、元数据存储部11(检索轮次信息存储部；元数据存储)、磁盘设备12(数据存储部；物理盘驱动器)和缓存内存14(临时数据存储部；先期知识(Forward Knowledge)缓存)。此外，存储系统1包括通过将程序安装到运算设备中来构造的恢复管理部分13(数据检索控制部；还原管理器)和缓存内存控制部15(临时数据控制部)。

实际上，由上述的存储系统1所包括的部件由运算设备——诸如CPU(中央处理单元)和存储设备——诸如由在图2中示出的加速器节点2和存储节点3中的每一个所包括的硬盘驱动器配置。

元数据存储部11是存储设备，诸如硬盘驱动器。元数据存储部11将包括信息——诸如在恢复数据时要检索的块数据的顺序和实际数据块的地址——的元数据与流识别符相关联并且存储该元数据和该流识别符。

例如，在通过备份过程来将块数据存储到磁盘设备12中时将上面提到的元数据存储到元数据存储部11中。一般而言，在执行恢复时，按照与已经写入块数据的顺序相同的顺序来检索块数据。因此，通过存储如上所述的元数据以便与流识别符相关联，有可能在执行恢复时按照与已经写入块数据的顺序相同的顺序来检索块数据。

进一步地，在该示例性实施例中的存储系统1在执行对在缓存内存14中的块数据的存储状态的控制(例如，删除由缓存内存14存储的块数据)时使用如上所述的元数据，将在稍后对此进行描述。换言之，在该示例性实施例中的存储系统1具有基于上述的元数据的缓存逐出策略(用于从缓存中删除数据的策略)。

磁盘设备12是存储设备，诸如硬盘驱动器。在该示例性实施例中的磁盘设备12以去重状态来存储块数据。

进一步地，如上所述，在该示例性实施例中的存储系统是内容可寻址存储系统。因此，存储系统1通过使用内容地址来将数据存储到磁盘设备12中。

现在，将对在磁盘设备12存储块数据时执行的过程的示例进行描述。例如，当请求存储系统1写入某个文件时，存储系统1按照给定量(例如，64KB)来将请求写入的文件划分成块数据。然后，基于通过划分获得的块数据的数据内容，存储系统1计算表示该数据内容的唯一散列值(hash value)。之后，存储系统1通过使用所计算的散列值来检查是否已经将具有该散列值的块数据存储在磁盘设备12中。然后，在未将这样的块数据存储在磁盘设备12中的情况下，存储系统1将块数据写入磁盘设备12。

在该示例性实施例中的磁盘设备12存储以上面的方式写入的块数据。换言之，磁盘设备12根据需要以在磁盘中向后添加新的块数据的方式存储块数据。具体的，例如，参照图4，为了对数据A₁、A₂和A₃进行备份，以A₁、A₂和A₃的顺序来将块数据写入磁盘设备12。然后，为了在上面的过程之后对数据A₁、A₂、B₁和A₃进行备份，在数据A₁、A₂和A₃之后将新数据B₁写入磁盘设备12。然后，为了在上面的过程之后进一步对数据A₁、C₁、B₁、A₃和C₂进行备份，在数据A₁、A₂、A₃和B₁之后将新数据C₁和C₂写入磁盘设备12。

因此，磁盘设备12存储通过被采用来进行去重备份的流行方法来写入的块数据。可以在需要时改变将块数据写入磁盘设备12的条件、要写入的块数据的内容等。例如，可以将磁盘设备12配置以使得检测共同率并且依赖于所检测到的共同率来写入块数据，该共同率表示配置写入划分的块数据的目标数据中的给定范围的多个连续块数据与已经顺序地存储在磁盘设备12中的给定范围的多个块数据之间的共同部分的比率。

恢复管理部分13基于从备份系统4接收到的流识别符来执行数据的恢复。换言之，恢复管理部分13从备份系统4接收给出了对数据的恢复的指令的流识别符，从而复原由该流识别符指示的文件。

具体地，在从备份系统4接收到流识别符后，恢复管理部分13从元数据存储部11获取对应的元数据的一部分。此外，随着该恢复的进行，恢复管理部分13从元数据存储部11获取附加元数据。因此，恢复管理部分13根据该恢复的进行程度来从元数据存储部11获取元数据。同时，恢复管理部分13可以一次获取所有元数据。

然后，恢复管理部分13基于由所获取的元数据指示的块数据的检索顺序来获取由存储系统1存储的块数据。具体的，在缓存内存14存储待获取的目标块数据的情况下，恢复管理部分13从缓存内存14获取目标块数据。另一方面，在缓存内存14未存储待获取的目标块数据的情况下，恢复管理部分13给出将恒定大小或可变大小的组块(chunk)形式的数据从磁盘设备12加载到缓存内存14的指令。换言之，在缓存内存14未存储待获取的目标块数据的情况下，将在磁盘设备12中的连续区域中写入的具有给定大小的连续块数据(例如，四个连续块数据)加载到缓存内存14中。然后，恢复管理部分1从缓存内存14获取目标块数据。

进一步地，在该示例性实施例中的恢复管理部分13使得缓存内存14基于从元数据存储部11获取的元数据来存储将在稍后描述的块数据轮次信息141。如稍后描述的，缓存内存控制部15通过使用块数据轮次信息141来执行对在缓存内存14中的块数据的存储状态的控制。将在稍后对块数据轮次信息141和缓存内存控制部15的细节进行描述。

缓存内存14是存储设备，诸如半导体内存。参照图5，例如，缓存内存14存储作为基于元数据的信息的块数据轮次信息141和指示从磁盘设备12获取的块数据的数据信息142。

块数据轮次信息141是基于如上所述的元数据来生成的信息。例如，块数据轮次信息141是针对每个块数据示出了被包括在由恢复管理部分1检索的元数据中的待检索块数据的轮次的信息。如在图6中示出的，块数据轮次信息141具有如下结构：其中用于识别块数据的块数据识别符与示出了待检索块数据的轮次的轮次信息相关联。

块数据识别符是用于识别块数据的信息。例如，块数据识别符是基于块数据的数据内容来计算的散列值的一部分(短散列)。同时，块数据识别符可以是整个散列值。

轮次信息是示出了由与轮次信息相关联且被存储的块数据识别符指示的检索块数据的轮次的信息。具体的，例如，轮次信息表示待检索块数据的轮次，该轮次在由恢复管理部分1当前正检索的块数据的轮次之后。例如，在恢复管理部分13正检索第78个块数据的情况下，轮次信息表示在待检索目标块数据的轮次当中的第79个之后(或者在第78个之后)的轮次。

轮次信息不一定需要准确地指示待检索的每个块数据的轮次。换言之，轮次信息仅需要指示在根据流识别符来开始的一系列检索过程中的粗略轮次。因此，例如，轮次信息可以是示出了通过按照给定大小来将一系列检索过程划分成多个区段而获得的划分区段的轮次的信息。

数据信息142是示出了从磁盘设备12获取的块数据的信息。例如，如在图7中示出的，将数据信息142构造为标准映射，在该标准映射中，内容地址(例如，如上所述，基于块数据的数据内容来计算的散列值)是密钥并且数据是值。

进一步地，在该示例性实施例中的数据信息142包括下一轮次信息，该下一轮次信息是关于待在下一次根据流识别符来开始的块数据检索中待检索目标块数据的轮次的信息。例如，图7中的第一行示出了待在下一次检索的具有内容地址“d34mf79”的块数据的轮次是“79”。换言之，从图7中的第一行发现：在根据流识别符来开始的一系列检索过程中，待在下一次检索的具有内容地址“d34mf79”的块数据的轮次是第79个。例如，基于块数据轮次信息141来获得被包括在数据信息142中的下一轮次信息。

进一步地，例如，根据下一轮次信息来对在该示例性实施例中的数据信息142进行重排序(排次(sort))。具体的，基于下一轮次信息来以递减顺序对数据信息142进行重排序。换言之，以待在下一次检索较早的轮次的顺序来对数据信息142进行重排序并存储。

缓存内存控制部15通过使用由缓存内存14存储的块数据轮次信息141来执行对在缓存内存14中的块数据的存储状态的控制。具体的，在缓存内存14存储(或者正在存储)预定阈值或者更多数目的块数据的情况下，缓存内存控制部15删除检索轮次离待由恢复管理部分13检索的块数据的轮次远的块数据。

因此，缓存内存控制部15根据与待由恢复管理部分13检索的目标块数据的检索轮次的距离程度来删除由缓存内存14存储的块数据。缓存内存控制部15执行这样的过程，从而防止缓存内存14变满。

例如，存储系统1具有元数据存储部11、盘存储部分12、恢复管理部分13、缓存内存14和缓存内存控制部15，它们具有如上所述的配置。

随后，将参照图8和图9对在恢复管理部分13获取块数据时执行的过程的细节进行描述。

首先，参照图8，将对缓存内存14存储待获取的目标块数据的情况进行描述。具体地，例如，将对恢复管理部分13正获取具有内容地址“d34mf”的块数据作为第79次检索的情况进行描述。

参照图8中的(1)，发现缓存内存14存储具有内容地址“d34mf”的块数据。因此，恢复管理部分13从缓存内存14检索目标块数据。进一步地，随着恢复管理部分13对块数据的检索，缓存内存控制部15更新块数据轮次信息141和数据信息142(见图8中的(2))。具体的，参照图8，发现在第79次检索之后第181次检索被排程(schedule)来检索具有内容地址“d34mf”的块数据。因此，缓存内存控制部15执行以下过程：根据块数据轮次信息141和数据信息142来将具有内容地址“d34mf”的下一次待检索的块数据的轮次从第79次更新为第181次。此外，缓存内存控制部15基于所更新的轮次来以递减顺序对数据信息142进行排次。因此，如图8中的(3)中示出的，具有内容地址“d34mf”的块数据被移动至在具有内容地址“9bgR4”的块数据下面的位置。因此，随着恢复管理部分13从缓存内存14检索块数据，对块数据轮次信息141和数据信息142进行更新。

例如，预见到在从缓存内存14检索块数据之后某些块数据不具有待在下一次检索的轮次(未排程在下一次检索该块数据)的情况。在这样的情况下，可以将缓存内存控制部15配置为从缓存内存14删除该块数据。

接下来，参照图9，将对缓存内存14未存储待检索的目标块数据的情况进行描述。具体的，例如，将对恢复管理部分13正获取具有内容地址“d34mf”的块数据作为第79次检索的情况进行描述。

在本文中，例如，由缓存内存14存储的块数据的数目的阈值为5。换言之，当由缓存内存14存储的块数据的数目超过五时，缓存内存控制部15删除由缓存内存14存储的块数据中的任何一个，使得由缓存内存14存储的块数据的数目变为五。

参照图9中的(1)，发现缓存内存14未存储具有内容地址“d34mf”的块数据。因此，例如，恢复管理部分13给出将在连续区域中写入的从具有内容地址“d34mf”的块数据开始的四个块数据从磁盘设备12加载到缓存内存14中的指示。因此，在图9中示出的情况下，连同具有内容地址“d34mf”的块数据，检索具有内容地址“F5kd9”、“pwQ2e”和“zc5Tf”的块数据。

作为从磁盘设备12检索块数据的结果，将七个块数据存储在缓存内存14中(图9中的(2))。因此，缓存内存控制部15删除块数据中的任何一个，使得由缓存内存14存储的块数据的数目变为五。在图9中的情况下，检索轮次离待由恢复管理部分13检索的目标块数据的检索轮次(第79)远的块数据是块数据“pwQ2e”和“zc5Tf”。因此，缓存内存控制部15删除块数据“pwQ2e”和“zc5Tf”。因此，将五个块数据留在缓存内存14中(图9中的(3))。

之后，恢复管理部分13和缓存内存控制部15执行参照图8描述的过程，从而从缓存内存14获取块数据并且还更新块数据轮次信息141和数据信息142。

这是对在恢复管理部分13获取块数据时执行的示例的描述。接下来，参照图10，将对在存储系统1恢复数据时的操作进行描述。

参照图10，存储系统1的恢复管理部分13接收给出从备份系统4恢复数据的指令的流识别符(步骤S001)。

恢复管理部分13从元数据存储部11获取与待恢复的文件有关的元数据(步骤S002)。然后，恢复管理部分13根据由所获取的元数据指示的块数据的检索顺序来开始对存储系统1所存储的块数据的获取。

具体的，在将待获取的目标块数据存储在缓存内存14中的情况下(步骤S003：是)，恢复管理部分13从缓存内存14获取该目标块数据(步骤S007)。进一步地，缓存内存控制部15更新缓存内存14。换言之，缓存内存控制部15执行更新块数据轮次信息141和数据信息142的过程。此外，缓存内存控制部15基于所更新的顺序来以递减顺序对数据信息142进行排次。

然后，在通过上述块数据获取而获取到由元数据指示的所有块数据的情况下(步骤S008：是)，存储系统1完成数据恢复并且结束该过程。另一方面，在待获取的块数据仍然剩余的情况下(步骤S008：否)，恢复管理部分13继续获取块数据。

同时，在未将待获取的目标块数据存储在缓存内存14中的情况下(步骤S003：否)，例如，恢复管理部分13给出将四个连续块数据从磁盘设备12加载到缓存内存14中的指令(步骤S004)。

然后，在存储在缓存内存14中的块数据的数目由于上述处理步骤而超出阈值的情况下(步骤S005：是)，缓存内存控制部15执行对在缓存内存14中的块数据的存储状态的控制。换言之，缓存内存控制部15基于块数据轮次信息151来删除检索轮次离待由恢复管理部分13检索的目标块数据的检索轮次远的块数据(步骤S006)。

之后，执行上述的处理步骤S007。换言之，恢复管理部分13从缓存内存14获取目标块数据，并且缓存内存控制部15更新缓存内存14(步骤S007)。同样，在由缓存内存14存储的块数据的数目不大于阈值的情况下(步骤S005：否)，以与上述方式相同的方式来执行处理步骤S007。

然后，在通过上述的块数据获取而获取到由元数据指示的所有块数据的情况下(步骤S008：是)，存储系统1完成数据恢复并且结束过程。另一方面，在待获取的块数据仍然剩余的情况下(步骤S008：否)，恢复管理部分13继续获取块数据。

因此，在该示例性实施例中的存储系统1具有元数据存储部11和缓存内存控制部15。利用这样的配置，缓存内存控制部15可以通过使用基于由元数据存储部11存储的元数据所生成的块数据轮次信息来执行对在缓存内存14中的块数据的存储状态的控制。换言之，缓存内存控制部15可以基于块数据轮次信息来删除检索轮次离待由恢复管理部分13检索的目标块数据的检索轮次远的块数据。因此，有可能降低在重用之前删除由缓存内存14存储的块数据的风险以及保持完全不必要的块数据被存储在缓存内存14中的风险。因此，有可能降低从磁盘设备12检索重复的块数据的频率，并且有可能抑制由在单个流中多次出现的块数据所致使的检索性能的降低。换言之，有可能实现可以解决难以抑制检索性能的降低问题的存储系统1。

在该示例性实施例中，缓存内存14存储块数据轮次信息141。然而，必要时，例如，可以由缓存内存14来存储块数据轮次信息141。

<第二示例性实施例>

接下来，在本发明的第二示例性实施例中，将对存储系统6进行描述，所述存储系统6依赖于在写入目标数据中的多个连续块数据与已经被顺序地存储在磁盘设备12中的多个块数据之间的共同部分的比率来重写重复的块数据。

参照图11，在该示例性实施例中的存储系统6具有与在第一示例性实施例中描述的存储系统1的配置类似的配置。此外，除了上述部件之外，存储系统6还包括通过将程序安装到运算设备中而构成的数据划分部66、块删除部分67和数据写入部68。将省略对在第一示例性实施例中描述的部件的描述。

如在第一示例性实施例中一样，存储系统6具有通过使用内容地址来将数据存储到磁盘设备12中的功能。具体的，如稍后描述的，存储系统6通过划分和分布数据并且利用内容地址指定存储位置来存储数据。下面将参照图12、图13和图16来对使用在存储系统6中的内容地址的数据写入过程进行描述。

首先，存储系统6接受被请求写入的文件A的输入，如由图12和图13中的箭头Y1所示。然后，数据划分部66按照预定容量(例如，64KB)来将文件A划分成块数据D，如图12和图13中的箭头Y2所示(图16的步骤S101)。

随后，基于划分块数据D的数据内容，块检测部67计算表示该数据内容的唯一散列值H(图13的箭头Y3)。例如，通过使用预设散列函数根据块数据D的数据内容来计算散列值H。

随后，通过使用文件A的块数据D的散列值H，块检测部67检查是否已经存储了块数据D(图16的步骤S102)。具体的，首先，在已经存储了块数据D的情况下，将其散列值H与表示其存储位置的内容地址CA相关联并且注册在MFI(主片段索引)文件中。因此，在存储之前所计算的块数据D的散列值H存在于MFI文件中的情况下，块检测部67可以判断已经存储了具有相同内容的块数据D(图13的箭头Y4，在图16的步骤S103处的“是”)。在这种情况下，从MFI文件获取与在MFI中注册的散列值H相关联并且与在存储之前的块数据D的散列值H一致的内容地址CA。然后，返回该内容地址CA，作为请求写入的块数据D的内容地址CA。

然后，数据写入部68将返回的内容地址CA所参考的已经存储的数据用作请求写入的块数据D(图16的步骤S108)。换言之，将返回的内容地址CA参考的区域选派为请求写入的块数据D的存储目的地被视为等效于存储请求写入的块数据D。因此，消除了将请求写入的块数据D实际存储到磁盘设备12中的需要。

进一步地，当块检测部67判断还未存储请求写入的块数据D时(在图16的步骤S103处的“否”)，数据写入部68按照以下方式来写入请求写入的块数据D(图16的步骤S107)。首先，数据写入部68对请求写入的块数据D进行压缩，并且如图13的箭头Y5所示，按照预定容量来将数据划分成多个片段数据。例如，数据写入部68将数据划分成如图12中的附图标记D1至D9示出的九条片段数据(划分数据71)。此外，数据写入部68生成冗余数据，使得即使当划分片段数据中的一些丢失时，也可以恢复原始块数据，并且将冗余数据添加至划分片段数据71中。例如，数据写入部68添加如图12中的附图标记D10至D12示出的三片片段数据(冗余数据72)。因此，数据写入部68生成数据集70，该数据集70包括由九条划分数据71和三条冗余数据72配置的十二条片段数据。

随后，数据写入部68将对以上面提到的方式生成的数据集进行配置的片段数据分别分布并且存储到形成在存储设备(磁盘设备12)上的存储区域中。例如，在生成如图12中示出的十二条片段数据D1至D12的情况下，数据写入部68将片段数据D1至D12逐个分别存储到在多个存储设备中形成的数据存储文件中(参照图13的箭头Y6)。

随后，存储系统6生成并管理表示以上述方式存储的片段数据D1至D12的存储位置的内容地址CA，即待从片段数据D1至D12恢复的块数据D的存储位置。具体的，存储系统6通过将基于存储的块数据D的内容计算的散列值H的一部分(短散列：例如，散列值H的初始8B(字节))与表示逻辑存储位置的信息进行组合，来生成内容地址CA。然后，将该内容地址CA返回至存储系统6中的文件系统(图13的箭头Y7)。存储系统6将识别信息——诸如备份目标数据的文件名称与内容地址CA相关联并且在文件系统中管理它们。

进一步地，存储节点3中的每一个将块数据D的内容地址CA与块数据D的散列值H相关联，并且在MFI文件中管理它们。因此，内容地址CA与指定该文件的信息、散列值H等相关联，并且将内容地址CA存储到加速器节点2或者存储节点3的存储设备中。

当以上述方式将请求写入的数据写入存储系统6时，存在以下情况：将通过划分数据获得的多个块数据分散并且存储在如上所述的磁盘设备12中。在这种情况下，存在检索性能降低的担忧，但是在该示例性实施例中的存储系统6还具有以下功能以便解决这样的问题。下面，将参照图14至图16来对该功能进行详细描述。

首先，如上所指出，块检测部67检查是否已经将具有与通过划分与写入请求有关的数据A而获得的块数据相同内容的块数据存储在磁盘设备12中(图16的步骤S101和S102)。在图14示出的示例中，首先，块检测部67将通过划分与写入请求有关的数据A而获得的块数据1确定为此时要进行存储过程的目标块，并且检查具有与目标块相同内容的块数据是否存在于存储在磁盘设备12中的数据B中。

然后，当具有与目标块数据相同内容的块数据1也存在于磁盘设备12中时(在图16的步骤S103中的“是”)，如图14中的阴影部分所示，块检测部67从在与写入请求有关的数据A中的目标块(块数据1)获取连续的多个块数据。在图14示出的示例中，块检测部67获取由配置在与写入请求有关的数据A中的预定范围的块数据1至8组成的连续块数据A1。块检测部67还从存储在磁盘设备12中的数据B当中获取存储在与具有与目标块相同内容的块数据1连续的区域中的多个块数据。即，在图14示出的示例中，块检测部67获取由配置在数据B中的预定范围的块1、C、B、7和G组成的连续块数据B1。例如，从与写入请求有关的数据A当中获取的所述连续块数据A1是与5MB的容量相对应的块数据，并且例如，从在磁盘设备12中的数据B当中获取的连续块数据B1是与2MB容量对应的块数据。因此，连续块数据A1和B1的容量可以彼此不同，或者可以相同。

此外，块检测部67检测共同率，该共同率表示被包括在从与如上所述的写入请求有关的数据A当中获取的相继的块数据A1中的相应块数据与被包括在从磁盘设备12获取的相继的块数据B1中的相应块数据之间的共同部分的比率(图16的步骤S104)。例如，块检测部67通过使用如上所提及的块数据中的每一个的散列值来检测彼此一致的块数据的数目。在图14示出的示例中，两个块数据1和7在连续块数据A1和B1中是共同的，并且块检测部67将其比率检测为共同率。

之后，数据写入部68依赖于如上所述的由块检测部67检测的共同率的值来按照以下方式写入块数据。首先，当共同率大于预设值时(例如，当大于50％时)(在图16的步骤S105处的“否”)，数据写入部68对与写入请求有关的数据A的目标块(块数据1)执行通常的写入过程。换言之，因为已经将具有与同写入请求有关的数据A的目标块相同内容的块数据存储在磁盘设备12中，所以数据写入部68执行参考已经存储在磁盘设备12中的块数据的过程，并且不执行重复存储(图16的步骤S105)。

因此，当连续块数据之间的共同率较大时，可以说，在与写入请求有关的数据A的目标块之后的其它块数据也被存储在具有与磁盘设备12中的目标块相同内容的块数据之后的预定范围中的区域中。因此，数据写入部68对如上所述的目标块执行通常的存储过程。之后，数据写入部68对下一目标块——即与写入请求有关的数据A的块数据2执行如上所述的相同过程。因此，在稍后检索与写入请求有关的数据A时，有可能通过检索已经存储的数据B的连续块数据来有效率地检索数据A。此外，因为还执行了对块数据的重复存储的消除，所以有可能减小存储容量。

另一方面，当共同率等于或者小于预设值时(例如，当等于或者小于50％时：可以是30％或者其它值)(在图16的步骤S105中的“是”)，数据写入部68将与写入请求有关的数据A的目标块(块数据1)重新写入磁盘设备12(图16的步骤S106)。即，在图14示出的示例中，因为彼此一致的共同块只有两个并且共同率等于或者小于预设值，所以，尽管已经将块数据1存储在磁盘设备12中，但数据写入部68也将块数据1写入磁盘设备12作为待重写的块数据(参照图15)。在写入时，将待重写的块数据1写入磁盘设备12内已经写入数据的区域的末尾。之后，以与上述方式相同的方式来对与写入请求有关的数据A的下一块数据2执行图16中的处理步骤S101至S108。例如，在还未将块数据2存储在磁盘设备12中的情况下，将块数据2写入在已经被如上所述来重写到磁盘设备12内的块数据1旁边的区域。

因此，当连续块数据的共同率较小时，可以说，以分布状态来将与写入请求有关的数据A的目标块和在该目标块之后的块数据存储在磁盘设备12中。因此，数据写入部68重新写入与写入请求有关的数据A的目标块。因此，在稍后检索数据A时，很可能通过检索写入磁盘设备12中的连续区域中的块数据，可以一起检索配置数据A的多个块数据，并且可以提高检索性能。

当块检测部67检测到与写入请求有关的连续块数据与已经如上所述来存储的连续块数据之间的共同率时，在连续块数据中的每一个中的块数据的顺序不重要。即，如果具有相同内容的块数据存在于连续块数据中的每一个中的任何位置中，则块检测部67检测到该块数据是共同的。然后，块检测部67基于处于共同的块数据的数目来检测共同率。该共同率的值可以是处于共同的块数据的数目的值，或者可以是处于共同的块数据在连续块数据中的比率。因此，不考虑在连续块数据中的每一个的块数据的顺序来检测共同率，这是因为，在检索时，有可能通过检索在磁盘设备12中的连续区域中写入的连续块数据来同时检索彼此相关的相邻块。

进一步地，如上所指出，数据写入部68并非始终重新地写入块数据，而是仅在满足以下条件时重新写入块数据。例如，数据写入部68相对于在与写入请求有关的数据A当中(例如，在与当前写入请求有关的一系列流数据当中)已经写入磁盘设备12的数据的容量来计算以重复的方式重新写入磁盘设备12的块数据的容量的比率，并且在该比率等于或者小于预定比率(例如，5％)时写入该块数据。因此，有可能限制重复的并且存储在磁盘设备12中的块数据的量。此外，通过限制重新写入磁盘设备12的容量，有可能限制由于重写而导致的写入速度的降低。再次写入块数据的条件可以是任何条件。例如，条件可以是：使得写入的块数据的容量等于或者小于先前依赖于磁盘设备12的容量所设定的容量。

进一步地，可以将数据写入部68配置为：当相同的块数据在与写入请求有关的一系列流数据内出现时，仅将在用于写入磁盘设备12的一系列流数据内最先出现的块数据作为目标。

在图17示出的示例中，发现相同的块数据“1”在与写入请求有关的一系列流数据内出现两次。在这样的情况下，数据写入部68将第一块数据“1”作为目标以供写入(执行图16中的步骤S101至S108)。另一方面，可以将数据写入部68配置为执行参考过程而无需判断是否再次写入再次出现的块数据“1”(加阴影的块数据“1”)。

如在第一示例性实施例中描述的，根据该示例性实施例的存储系统6可以通过有效率地使用缓存内存14来限制检索性能的降低。因此，在如上所提到的情况下，认为可以通过有效率地使用缓存内存14而无需再次执行写入过程来限制检索性能的降低。因此，在相同块数据出现在一系列流数据内的情况下，认为可以通过仅将首先出现在一系列块数据内的块数据作为目标以用于写入磁盘设备12，来实现限制检索性能的降低的有效率重写判断。

进一步地，在判断相同块数据是否已经出现在一系列流数据内时，需要使用布隆(Bloom)过滤器。认为使用布隆过滤器使得能够利用相对小的内存来进行判断。即使当使用布隆过滤器并且结果是误报(false positive)时，也如上所述来执行是否再次写入的判断。因此，将不存在任何问题。

因此，根据在该示例性实施例中的存储系统6，有可能在执行对重复存储的消除的同时，限制块数据在磁盘设备12内的整个存储区域中的分散。因此，在稍后检索数据时，有可能限制对大量磁盘的扫描，并且有可能限制检索性能的降低。另一方面，为了限制检索性能的降低，允许对块数据的重复存储，但是有可能通过限制重复存储的容量来限制存储容量的增加。

<第三示例性实施例>

在本发明的第三示例性实施例中，将对具有临时数据控制部的存储设备8进行描述，该临时数据控制部基于由检索轮次信息存储部84存储的检索轮次信息来执行对在临时数据存储部82中的块数据的存储状态的控制。在该示例性实施例中，将对存储设备8的配置的概述进行描述。

参照图18，存储设备8具有数据存储部81、临时数据存储部82、数据检索控制部83、检索轮次信息存储部84和临时数据控制部85。

数据存储部81存储去重的块数据。进一步地，临时数据存储部82临时存储从数据存储部81获取的块数据。

检索轮次信息存储部84存储作为关于待检索块数据的轮次的信息的检索轮次信息。

数据检索控制部83检索存储在数据存储部81中的块数据并且存储到临时数据存储部82中，并且从该临时数据存储部82检索该块数据。具体的，在该示例性实施例中的数据检索控制部83使得临时数据存储部82基于从检索轮次信息存储部84获取的检索轮次信息来存储从数据存储部81获取的块数据。

临时数据控制部85控制存储在临时数据存储部82中的块数据的存储状态。具体的，在该示例性实施例中的临时数据控制部85基于检索轮次信息来控制在临时数据存储部82中的块数据的存储状态。

因此，在该示例性实施例中的存储设备8具有检索轮次信息存储部84和临时数据控制部85。利用这样的配置，临时数据控制部85可以基于由检索轮次信息存储部84存储的检索轮次信息来控制在临时数据存储部82中的块数据的存储状态。换言之，有可能基于检索的轮次来控制在临时数据存储部82中的块数据的存储状态。因此，有可能减小在重用之前删除由临时数据存储部82存储的块数据的风险和完全不必要的块数据被保持存储在临时数据存储部82中的风险。因此，可以抑制检索性能的降低。

<第四示例性实施例>

下面将以研究论文的形式来对本发明的第四示例性实施例进行描述。

<第1章引言>

<1.1动机>

数字世界日渐强大。自2007年以来，[35]国际数据公司(International Data Corporation)一直在估计所谓的数字宇宙的大小或者在一年中创建和复制的数字信息量。最新的研究[34]显示，数字宇宙每两年便会大约翻一番，在2020年会实现惊人数目的40万亿千兆字节(见图19)。

由于几乎所有创建的新数据都是以数字方式存储的，因此，创建的数据量的指数增长直接导致存储需求的类似增加。交易数据存储量中的年平均增长为30-50％。WORM数据的增长(写一次读多次)，例如，医疗数据(诸如，X射线)、金融、保险、多媒体数据，为每年100％[19]。此外，在许多区域，立法[1、59]需要长时间保留数据，这进一步增加了存储需求。容易想象对存储无法容易地重新创建的公司战略性数据或信息的需要，但是最近的事件大体上已经示出了对于甚至公共互联网内容的存档需求。其原因在于保留对于后代具有“文化重要性”的空间的Web。这样的项目由英国国家图书馆(British Library)[11]主导，并且其已经在英国互联网上收集了数千个网站以及它们随时间的演进。

最新报告[33]还示出，我们近75％的数字世界都是副本，这意味着只有25％的创建的数据是唯一的。当我们在二级存储市场内查看这个数字时，其可以指示存储了甚至少于5％的唯一数据[36、83]。该事实是自从具有重复消除的系统在大约10年前出现以来在备份市场上变得非常普及的关键原因中的一个。实际上仅仅必须存储所有数据的很小百分比显着降低了基于磁盘的备份存储的价格，该基于磁盘的备份存储支持诸如便于访问来自过去的任何备份和通过网络来有效率复制的特征以供灾难复原。此外，由可用的系统递送的高写入吞吐量[56、64]确保小备份窗口，该小备份窗口连同微小的存储成本使更频繁的备份服务成为可能(排程以及保留两者)。

据估计[2]，这样的系统——被称为特制的备份器材(PBBA)的市场在2016年将从2011年的24亿美元(经运4.65亿千兆字节)增长到58亿美元(经运86亿千兆字节)(见图20)。

通过关键技术——诸如分布式散列表[24]、流组块[67]、纠删码(erasurecoding)[80]、快速重复消除[83]等来使能对具有重复消除的辅助存储系统的引入。已经投入了大量的努力来测试该方法在减少以下两方面的有效性：执行备份所需的时间和保存该备份所需的存储空间[23、66、51]。该效果体现在市场流行度上。如今，具有数据去重的存储系统带来了备份带宽的新记录[64、32、56]，并且世界上充斥着由许多供应商提出的各种去重解决方案[77、3、26、29、31、39、55、65、74]。实际上，去重已经成为备份系统的不可缺少的特征中的一个[4、8]。

<1.2问题陈述>

在标准磁性硬盘驱动器(HDD)上的数据碎片化出现在将两条或者更多条一起使用的数据彼此远离地存储时，从而降低了每次访问该数据所获得的性能。不幸的是，去重备份系统的碎片化问题与其主要特征——去重本身严格相关。在大多数现代去重系统中，在写入数据之前，将该数据分成相对小的块(例如，8KB)。仅在验证了块唯一性之后，才将其存储在磁盘上。否则，返回已经存在的块的地址。因为这样的块有可能被存储为远离最新近写入的块，所以对完全相同的数据流的恢复变得低效。碎片化由此开始。

<1.2.1碎片化对恢复带宽的影响>

恢复带宽(在需要时恢复该数据所需的时间)是描述去重系统的性能的主要因素中的一个，连同数据去重率(可以节省的存储空间)和最大写入性能(备份窗口长度)一起。由常规客户在他的工作环境中实现的实际恢复性能通常可以不同于由系统制造商出于各种原因所示出的恢复性能[62、63、61、46、81]。具体的，恢复带宽对于保存到空系统的初始备份而言通常较为良好，但是对于后续备份而言则会劣化[41、48、53]。其主要原因是由去重所致使的不同种类的数据碎片化。它们是：

版本间碎片化-由具有相同数据的定期备份(每天、每周、每月)所导致，

内部流碎片化-由相同块在单个备份中出现多次所导致，

全局碎片化-由彼此无逻辑连接的相同块在备份中出现所导致。

在图21中呈现了具有上述因素中的每一个的示意性成本，表现为恢复带宽降低。在本文中，我将深入研究两个主要因素(如在进一步分析期间发现的)：版本间碎片化和内部流碎片化。

<1.2.2版本间碎片化>

只有在具有在线(in-line)去重的系统中才能观察到版本间碎片化，这种系统在当今的市场上最为流行[2]。因为在该解决方案中从不存储重复块，所以，这样的碎片化引起逻辑上属于最近备份的数据跨较旧备份的多个位置而分散。随着每个备份这种影响变得更大，因为其数据中的越来越多实际上位于意味着不断增多数目的不同磁盘位置的不断增多数目的先前备份中。取决于数据集、其特性描述和备份模式，我的实验示出读取性能从几个百分比降低到超过50％。因为我的数据集涵盖了不超过50个连续备份，所以，我预计在执行更多备份时，该百分比甚至会更高。

可以利用称为后处理(离线)的前向(forward-pointing)去重来避免后续备份的这种最严重(随着不断增加)的碎片化。在这样的方法中，在没有任何去重的情况下写入备份，并且稍后在后台执行去重以保留块的最新副本[45、81]。因此，碎片化不增加，并且最新的备份不随着其存期(age)而变得更碎片化。由于最新的备份是最有可能要恢复的，因此，该解决方案似乎很有前景。不幸的是，其存在许多问题，包括：(1)由于在去重之前的数据所需要的空间的提高的存储消耗；以及(2)因为写入新的重复副本通常比在线来对这样的数据进行去重慢得多(几倍)，所以高度重复的数据的写入性能显着降低[44、32]。后一个问题的出现是因为写入新数据需要跨网络来传输该数据并且将该数据提交至磁盘，而基于散列的去重只需要将块散列与存储在系统中的块的散列相比较，从而确保小得多的资源(网络、处理器和磁盘)使用。

为了说明版本间碎片化问题，我们假设每周仅将一个文件系统的完整备份保存到具有后向去重的系统。在这样的系统中，与在线去重的情况一样，块的最旧副本被保留，因为尚未写入新的副本。

通常，不会在两个备份之间较多地修改文件系统，并且在第二次备份之后，检测到许多复本并且不再次进行存储。最后，将第一备份放置在连续存储空间中，并且将第二备份的所有新的块都存储在当前占用区域的末尾之后(见图22)。在以下备份期间继续这样的场景。在某数目的备份之后，来自最新备份的块被分散在存储区域中各处。这导致读取数据需要大量的磁盘寻道，并且因此导致非常低的读取性能(见图22中的最后一个备份的恢复过程方案)。

这样的过程对于紧急恢复可能非常有害，因为上面的场景对于在线去重是典型的并且导致最新近写入的备份的最高碎片化(当用户数据丢失时最可能需要恢复的备份)。

<1.2.3内部流碎片化>

还可以引入较大恢复带宽弊端的因素是内部流碎片化。即使内部流碎片化与先前的碎片化一样是由去重引起的，其也仅限于单个备份。这引起不同的一组特性，诸如，对相同数据的所有备份版本和受影响的各种去重备份系统(包括离线)产生相当恒定的影响。我的实验示出，内部流去重——内部流碎片化的确切原因通常非常明显，因为来自单个备份的17％至30％的块在备份内出现超过一次。默认情况下，通过去重机制来消除它们，从而为用户数据节省宝贵的空间。不幸的是，这种情况是以高达70％的性能恶化为代价的，这可以在有必要进行恢复时见到。进一步分析还示出，在备份系统中的恢复时通常使用的LRU缓存算法在所描述的场景中不是非常有效，通常使内存填满无用的数据。

足以来说明内部流碎片化问题的情况是，将具有某平均数目的内部重复块的单个数据流备份到具有去重的系统。因为系统仅存储每个块的一个副本，所以，将不再按照这样的方式来将通常连续的备份存储在磁盘上(见图23)。这导致读取数据需要大量的磁盘寻道，并且因此导致非常低的读取性能(见图23中的备份的恢复过程方案)。

最后，内部数据碎片化导致无效的缓存内存消耗和较低的恢复带宽二者。然而，该问题特性与由内部流碎片化引起的问题特性非常不同。首先，从第一个备份开始，针对来自数据集的所有备份对性能的影响或多或少是恒定的。其次，该问题以同样显著的方式影响所有去重系统(包括离线)。

<1.3论文贡献>

考虑到所描述的场景，本文的目标在于对写入性能和去重有效性二者无负面影响的情况下避免恢复性能的降低。换言之，理想的去重解决方案应当在没有由任何种类的碎片化致使的任何读取弊端的情况下，实现高写入带宽——如当前通过在线方法来提供的和高恢复性能。

本文的主要贡献是：

·基于从用户收集的真实踪迹，详细分析和描述了特定于具有去重(特别是在线)的存储系统的碎片化问题，

·识别出对于解决已发现的问题的算法的要求和可能的权衡，

·提出将利用先期知识的智能缓存以作为通过充分利用备份系统特性来大大提高读取缓存有效性并且处置内部流碎片化的解决方案，

·提出基于上下文的重写算法(CBR)来应对版本间碎片化，其不具有无去重损失，并且对备份写入性能影响最小，连同解决重要权衡的多个特征——诸如写入带宽、时延、恢复性能和对附加空间的临时使用)。

·分析了所提出的算法的要求的满意和权衡方案，以及基于真实用户踪迹的一组实验以证实所选择的解决方案的有效性。

·分析了碎片化问题的可扩缩性及其提出的解决方案。

<1.4论文大纲>

本文组织如下。下一章大体上提供了关于去重和存储系统的信息。在第3章中给出了本文的动机、对碎片化问题的性质的深入观察、其不同的来源和几个示例。第4章和第5章介绍了针对在具有去重的存储系统中出现的两个不同问题的解决方案。利用先期知识的智能缓存试图在存在内部流碎片化的情况下提供对读取缓存的有效使用，而基于内容的重写算法(简称CBR)处置内部流碎片化以便确保最有效的块布置以供将来恢复最新近的备份。在这两种解决方案之后是讨论和权衡。第6章包含对关于从不同用户收集到的真实踪迹的两种算法的评估，包括对性能结果、以及在实验中使用的假设和方法的讨论。本章还包括单独的和联合的实验、以及关于这两个解决方案的可扩缩性的部分。在第7章中对相关工作、以及针对碎片化问题的其它解决方案进行了讨论。最后，第8章包含结论、对可能的算法扩展的洞察和未来工作的其它方向。

<第2章备份和去重>

<2.1辅助存储系统>

<2.1.1要求>

根据其定义，备份是以防原件丢失或者损坏而对文件或者其它项目所作的副本。当谈到单个桌面的备份时，这样的看起来简单且容易的任务听起来不是很具有挑战性。然而当针对具有数百个用户的大中型公司时，该场景发生巨大的变化，每天将产生兆兆字节的数据，并且出于内部安全原因，要求每天晚上或者每个周末(短备份窗口)都要执行备份。不要忘记备份策略，该备份策略要求保留相同数据集的许多备份(每天/每周一次)，该许多备份彼此之间能够仅有几个字节不同，也不会忘记即使管理非常大的系统(拍字节级别)也是不容易的。一些人重视为每组数据设置单独弹性(resiliency)的可能性，而其他人将特征——诸如在需要时删除(在分布式环境中非常复杂[76])或者不间断更新以及容易的系统扩展视为最关键之处。容易且快速的远程复制以及价格——可能的最低价格还被视为重要的补充。人们可以期待，这两个约束中的每一个通常会引入不容易处置的权衡[23]。此外，人们需要记住关于备份系统存在的主要原因：紧急恢复。在没有快速恢复以最大程度减少昂贵的停机时间的情况下，所有其它特征似乎都没有多少吸引力。

重要的是，强调辅助(备份)存储和主存储之间的差异，这是理解后续章节所需要的(见图24)。后一种系统是按照与人们在其计算机中使用硬盘类似的方式针对日常任务使用的系统。而利用备份，我们会预期到巨大的流吞吐量、数据弹性和最大容量，此处，低时延对于所有操作(读取/写入/删除)甚至是要求随机存取的操作都是关键的[75]。另一方面，虽然很重要，但相同的主系统带宽和数据弹性不会是最需要的。当我们考虑特征(诸如，在每个备份操作的关键路径上发生的压缩、加密和数据去重)时，这样的小而微妙的差异甚至变得更大。

备份系统要求[23]：

·在紧急情况下的快速数据恢复

·高(并且可扩展的)容量

·相当大的备份带宽(允许小备份窗口)

·远程复制选项(仅优选来修改的数据)

·保持的数据的可配置弹性

·按需求删除

·无论系统的大小如何的易于管理、升级和存储增加

<2.1.2历史>

尽管第一台通用计算机是在1946年建成的并且备份演进似乎相当短暂，但也是非常剧烈的一次演进。第一个可用的穿孔卡可以存储少于100字节的数据，而最新的设备可以保持超过1TB的数据。在这样的短的时间段内的巨大飞跃示出了为让每个用户得到最大限度的计算机体验而投入到开发技术中的工作量。

对穿孔卡——可以被认为备份的第一种介质的使用要追溯到19世纪末。随着计算机的出现，很容易采用穿孔卡，以便成为(在20世纪50年代)用于机构计算(institutional computing)中的数据存储、录入和处理的最广泛使用的介质。穿孔卡对计算机程序员来说是必不可少的，因为它们被用于存储计算机的二进制处理指令。实际上，NASA使用穿孔卡和计算机来读取二进制处理指令以便执行计算，以作为到月球的第一次载人太空飞行的一部分。幸运的是，一次打一张精确的副本或者两张卡是一种简单的产生即时备份的方式。

随着对穿孔卡的使用的快速增长，存储穿孔卡变得麻烦；最终需要大型存储设施来容纳穿孔卡箱(见图26)。通过越来越流行的磁带解决了该问题。即便如此，直到20世纪80年代中期，仍然在使用穿孔卡程序[15，40]。

由于一卷磁带可存储多达一万张穿孔卡，因此，磁带作为在20世纪60年代用于备份的主要介质逐渐变得非常普及，。其可靠性、可扩缩性和低成本是使该技术成功成为20世纪80年代用来执行备份的最普及的方式中的翘楚的主要原因。在接下来的多年中，该技术得到了改进以便提供更高的带宽和更好的数据密度。2000年9月，由Hewlett-Packard、IBM和Seagate发起的联盟(其磁带部门脱离为Certance，并且现在是Quantum Corp.的一部分)发布了名为Linear Tape-Open(LTO)Ultrium的技术，该技术引入了发展和使用至今的共同标准。最新一代(LTO-6)于2012年6月公布并且提供了：6.25TB容量和400MB/s级别的数据传输速率，以及特征——诸如WORM(一次写入多次读取)、加密和分区等[78]。为了提供自动化并且同时向许多流传输/从许多流传输，具有许多磁带驱动器的专门的机器人/库是可用的(见图26)。

由于硬盘驱动器(HDD)的高价格、大尺寸和低容量，硬盘驱动器(HDD)的引入在备份市场中没有带来太大的变化。使随机存取数据成为可能的新技术首次被用在了台式计算机中，但是在20世纪80年代末，其也被用于备份。进一步地，由于独立磁盘冗余阵列(RAID)的引入，在该方向上的进一步开发是可能的，该独立磁盘冗余阵列(RAID)在较小的数据的世界中仍然是常见的，但是大小和弹性的限制对于大中型公司来说太严格。在2013年，单个3.5英寸的硬盘驱动器可以提供高达4TB的容量和超过200MB/s的传输速率。即使这些值与现代磁带可用的值相当，但是要支付的价格却高出几倍。

由网络附接存储(NAS)和存储区域网络(SAN)支持的局域网成为备份市场中的下一个大玩家。远程地保持数据使备份更方便(无需附接附加介质)，更快速且可容易地复制。此外，使用硬盘驱动器允许几乎即时存取任何数据和使用算法——诸如去重，这可以使备份更有效率并且成本更低。自新千年以来，不仅通过网络来附接备份系统，而且备份系统可以是能够提供之前不可能的特征的节点的单独的生活社区。由于在单个系统中使用了许多服务器，所以倘若发生了任何磁盘甚至是机器或者交换机故障，人们也可以利用自动愈合过程来获得智能数据弹性。此外，所有计算机的组合效力(power)可以提供高水平的吞吐量(超过900TB/hr[56])和容量(超过100PB[56])以便实现在短备份窗口中从许多不同源收集数据。即使当今可用的系统是相当局部的或者具有数据中心的大小，该系统也可以彼此对话以在大距离范围上复制数据来仅仅传递新的或者修改过的部分。另一方面，分类软件提供了一整套重要的特征，支持对集群的简便管理，并且提供接口，该接口通过网络接口——诸如NFS或者CIFS将系统导出为一个统一空间。磁盘驱动器的较低的价格、潜在无限制的缩放可能性、以及较高的密度，结合去重技术并且受远程复制、负载均衡、容错和快速恢复的支持，使得这些系统——被称为特指备份器材(见图27))成为如今中短期备份解决方案的首选[17、2]。

闪速存储似乎是当前基于转轴的磁盘在不同种类的使用中的合乎情理的继承者。闪速存储速度快，需要较少的功率，并且防止诸如存取大索引和流数据碎片化(不再需要流存取)等问题。不幸的是，闪速存储具有几个重大的缺点，这些缺点使其无法成为业务解决方案的良好选择，特别是需要大量存储空间的业务解决方案。即使我们可以找到价格低于每GB 1美元的SSD驱动器，其仍然离具有转轴的常规驱动器需要支付的0.05美元相差较远(个人研究：2013年6月)。具有这些价格并且最大容量通常小几倍，即使考虑到我们近年来曾经经历过的重大价格下跌的事实的继续，也很难断言任何演进。另一方面，此处的小演进是可能的，并且在缓慢地进行。如最近的研究表明，可以很容易地将SSD驱动器用于大型索引[82、43]以及用于提高去重吞吐量[49、21]，这对于当今的备份似乎非常有用。

在过去的30年中，出现了可以用作备份解决方案的许多其它介质，但是这些介质尚未普及，尤其在企业环境中。最常见的设备是不同种类的盘：软盘、压缩盘(CD)、通用盘(DVD)、HD-DVD、蓝光盘。随着每种盘的容量、传输速率和其它指标变得越来越好，但它们仍然不足以与硬盘或者磁带竞争。主要的问题往往在于：价格、存取时间、存储空间太小和管理复杂。

最近的备份思想被称为在线备份，并且与云概念有关。这种想法是一种备份数据的策略，该策略涉及通过专有或者公共网络来将数据的副本发送至非现场(off-site)服务器。该服务器通常由基于容量、带宽或者用户数目来向备份客户收取费用的第三方服务提供者托管。通常围绕客户端软件应用来构建在线备份系统，该客户端软件应用根据由客户已经购买的服务级别所确定的时程表运行。为了减少传输文件所耗的带宽量，服务提供者可能只在初始完整备份之后提供增量备份。由于其便利性，第三方云备份在小办公室和家庭用户中很受欢迎，因为不需要附加硬件的大支出并且可以在晚上运行备份，这意味着可以自动运行第三方云备份而无需人工干预。在企业中，云备份服务主要被用于仅将非关键数据存档。对于需要较短恢复时间目标(RTO)的关键数据来说，传统备份是更好的解决方案，因为在给定时间量内可以通过网络移动多少数据存在物理限制。当需要恢复大量数据时，数据可能需要在磁带或者一些其它便携式存储介质上来被运输[70]。此处最重要的问题还是数据安全性、可用性、私密性和服务提供者以某种未限定的方式来使用数据的风险。特别是大型公司会更偏好将敏感数据保持在他们自己的系统中，而不冒险交出控制权。重要的是声明此处使用的技术基本上与上述网络备份相同或者非常类似。不同的是双方所要求的协定、使用的软件和客户与服务提供者之间的交互的构思。

<2.2重复消除>

通常将去重定义为消除冗余数据的技术。当对数据进行去重时，保留重复信息的单个实例，而用指向该单个副本的指针来替换重复实例。整个过程对用户和应用完全隐藏，这使该过程易于使用并且不需要任何专用软件修改。

为了便于被比较和发现，每条数据需要比数据本身短得多的唯一识别符。在辅助存储中，基于待存储数据的内容来计算这样的识别符(通常使用散列函数)，并且使得便于使用专用索引来对任何现有的传入数据片进行定位。将以这种方式识别其数据的系统定义为内容可寻址存储设备(CAS)，并且其已经是超过10年的研究领域[66]。

<2.2.1特性>

粒度

数据去重通常可以以文件的级别或者块的级别来进行。前者消除重复文件，但是通常不是非常有效率的一种去重的方法，因为任何最小的修改都需要将整个文件再次存储为不同的文件[60]。块去重在文件内进行查找，并且将文件分成小块。然后，使用散列算法——诸如SHA-1或者SHA-256来处理每个这样的块，以便生成被存储和索引的唯一散列数。如果更新了文件，则仅存储改变的数据。即，如果仅仅是文档或者演示的几个字节发生了改变，则仅保存改变的块。该行为使块去重更有效率得多。然而，块去重占用更多的处理能力，并且使用更大的索引来跟踪各个块。

算法

块级的重复消除算法的两个主要抽象称为：固定大小组块和可变大小组块。在多次测试之后，结果表明：伴随可能的更新，具有固定长度的块不是很有效[66]。通过在文件的开始或者中间处简单修改几个字节，必须将所有以下内容重写为具有不同块边界的新数据以便保持其大小。另一方面，可变组块长度[50、83、23]利用专用算法(诸如，Rabin指纹识别[67])，该专用算法实现在发生任何修改之后立即同步块边界。由于这一点，可以将修改过的文件的以下部分切割成完全相同的块，然后可以在备份未修改的原始文件之后将该完全相同的块去重为已经存在的块。

通常，在现代系统中以这样的方式产生的块大小处于某些边界内(例如，4至12KB)，其具有在其中间某处的平均值。最常使用的平均值在4KB与64KB之间，并且对整体去重率以及一些其它系统特征——诸如去重的范围、数据碎片化有显著影响。一些专用算法试图通过允许在单个备份期间使用许多不同块大小(即，64KB与8KB)来优化这种影响。如研究显示的[69，42]，该结果相当具有前景。

应用点

辅助存储系统由执行备份的一组客户端使用。需要将每个备份流组块成块，同时对它们中的每一个进行散列计算以便验证其在系统中的存在。这些操作可以在客户端或者服务器侧上进行。前者——称为源端去重需要将专用软件安装在客户端上，但是以一些处理能力(散列计算)为代价，其可以提供低得多的网络使用率。另一方面，后者——称为目标端去重对客户端是完全透明的，仅通过网络接口来提供存储空间，并且因此，非常易于在内部执行散列和所有其它所需操作。两个选择在市场上都可获得，并且可以基于客户需求来对其进行部署。

应用时间

在具有目标端去重的系统内，存在两个群组，当应用该过程时，这两个群组在时间上不同。离线(后处理)去重[74、62、61]是一种最简单的方式，其中，在第一阶段中，将来自当前备份的所有数据连续地存储在系统中。在完成该操作之后，按照这样的方式在后台执行实际去重：以使得来自最新备份的块是用于从较旧备份消除重复的基础[61、45]。另一方面，这样的方法确保来自最新备份的所有数据都位于一个连续空间中，这使得更易于读取，但是另一方面，这指示多个不同的问题。然而，问题是备份性能降低了几倍，缺乏节约网络或者磁盘带宽(即，在客户端或者备份服务器上的去重)的可能性以及保持整个备份窗口的原始数据的价值(着陆区)所需的空间。即使可以通过较早地开始去重过程并且逐部分地(分级)执行该过程来最小化着陆区，但该操作所需要的系统资源将使当前备份更慢，这添加了又一个负面影响[13]。此外，离线过程变得相当昂贵，因为在每个备份之后，必须在整个存储空间中找到并且在后台删除其大小的约95％(假设20:1去重率)。

称为在线去重的另一种类确保在写入过程期间找到重复数据，并且从不存储已经存在于系统中的块。这需要快速算法以便在运行中验证块的存在，并且依赖于结果来返回重复的或者新的指针。这样的路径通常很复杂，但是通过确保在系统中未发现重复数据，其不需要在备份之后进行任何清理。同样，因为相较于将新的块存储在磁盘上，检查散列存在(通常在位于内存中的索引中[83])可以快三倍[41]，所以，其提供了更好的带宽。这种方法的问题是渐增的碎片化，将在本文的下一章中对此进行详细描述。

范围

去重的最终特性与其范围有关。由于出现的实现问题和技术问题，总是识别到存在于系统中的每个重复块的最直观的全局版本并不常见。主要问题是巨大的全局索引，该巨大的全局索引应当始终是最新的并且允许快速识别所需要的块。此处的问题中的一个是识别块是否是重复的。通常利用布隆过滤器[9]来进行该识别，并且该识别由分布式系统——诸如谷歌的Big Table[16]和DataDomain[83])使用。该识别有助于避免对无法找到的块的昂贵查找。另一方面，技术——诸如使用较大的块大小[23]并且利用组块局部性以用于索引缓存以及用于在磁盘上布局组块[83、68])减少了在RAM中所需要的数据量因此，只有较小百分比的请求需要存取位于磁盘上的全索引。当转到分布式环境时，问题更加复杂，这导致仅有一个商用系统具有全局去重(HYDRAstor[23])，该系统使用专门的分布式散列表[24]以便处置任务。

其它现有的解决方案是集中式解决方案(诸如，EMC Data Domain)或者使用以去重为代价而限制所需要的内存的不同种类的技术。例如，稀疏索引[44]是允许基于所计算的散列来仅对几个最相似的片段进行去重的一种技术，而Extreme Binning[6]利用文件的相似性以便实现由具有较低局部性的单独文件组成的工作负载的更好结果。

<2.2.2去重率>

去重率可以依赖于数据流特性描述、组块算法、块大小和保留策略而广泛地变化。如研究文章所证实的，还必须连同计算散列或者更新元数据并且存储/定位数据所需要的性能一起，来考虑与所有存储的数据有关的元数据大小[69]。最后，人们需要记住系统的可扩缩性和重构数据的时间问题。所有这些都会影响去重率，其范围可以为4:1到200:1和更大[47]。在聚合时，可以实现10至20倍或者更多倍(小于原始存储容量的5％)的压缩，该压缩倍数与利用其它源——商业[10、4]和科学[83、69、48]源二者确认的压缩倍数有一些偏差。

由于在第2.2.1节中描述的可变大小组块的优点，大多数现代备份系统都使用可变大小组块。如在许多文章[54、69]中示出的，可变块大小的平均值目标对数据去重率有显著的影响。当着眼于数据时，只有一种情况能总是期望较小的块在空间节省方面能表现得更好，但是需要记住可能出现的问题。对小型块的使用导致更高的内存需求(更大的索引)、备份性能劣化(更多的块要验证和传输)和致使恢复带宽问题的数据碎片化(更小的随机读取可能性)。此外，每个数据块需要小但醒目的元数据片，该元数据片不依赖数据大小而存储。不幸的是，当考虑到该问题时，可能会浪费掉通过应用较小的块大小而实现的所有节省。当着眼于市场时，使用的最常见的块大小是8KB(即，EMC Data Domain-全球领导者[29])，但是另一方面，存在与甚至64KB(NEC HYDRAstor[56])或者4KB(HP StoreOnce[38])块大小的竞争。

之后，每个单个备份将利用一些单独限定的块大小来进行最佳去重。此外，为了实现最佳结果，针对其修改方案，可以将流的每个部分划分成不同大小的片段。即使该问题大体上看起来极其复杂，但是出现的一些简化解决方案允许在单个备份期间使用两种大小的块。有关块应当较小或者较大的决定基于先前存储的信息。根据Romanski等人[69]，这样的方法可以实现使去重率提高15％至25％，其中比平均块大小提高了几乎3倍。

在计算重复消除率时经常被低估的因素是保留策略。因为去重的最大效力来自于根据相同数据的先前备份消除重复，所以，有关这样的备份的数目的信息对于计算的目的至关重要。假设我们的示例文件系统的大小为1TB，并且修改速率为每天1％的块的水平(为了简化计算，假设我们的备份在大小上不增加，并且每天修改随机的块)。具有了这样的系统，用户可以选择三个简单备份策略中的一个：每日、每周和每月。它们中的每一个限定待执行的完整备份的频率。在使用所述策略中的每一个一年之后，结果占用我们的系统的数据具有类似量(4.1TB至4.6TB)，但是写入的数据量(12TB至365TB)显著不同。因此，所述策略中的每个个计算出形成鲜明对比的去重率：78.49、11.48和2.91(见图28)。每个策略是唯一的并且具有不同的成本(即，在一个月期间花费在备份上的时间)，以不同的方式保护数据。该计算仅显示了如下事实：每个指定的情况是唯一的并且仅考虑去重率具有其自身的缺点。通常，备份(除了初始备份)中的重复的平均数目作为去重能力的指标似乎更精确。

当在增量备份和完整备份之间进行选择时，可以实现类似的效果。前者最可能需要较少的时间来执行，但是会需要更多的时间才能将数据最终恢复出来，这是因为在给定时间之前需要将最新的完整备份和所有增量拼接在一起。后者，即使其需要更多的时间，但是由于去重，其不会消耗更多的存储空间。同样重要的是，要注意，从统计角度来看，即使存储的数据类似，但是在这两种情况下的最终去重率看起来将大不相同。

压缩是在将数据存储在系统中之前通常应用的另一个任务。仅保留必要数据可能需要更多的处理器能力以在将来进行压缩和可能的解压缩，但是通常可以将整体数据缩减率(压缩率以及去重率)提高2或者更大的倍数。这样的空间节省通常值得努力，特别是对于较大的块大小，其中压缩变得更有效。

最后，对去重率的基本影响具有单独的备份流特性。流内容及其内部冗余是重要的开始。以邮箱为例，第一次备份可能会导致存储在系统中的唯一数据少于50％(将去重率提高2倍)，而对电影数据库的第一次备份不会显示出任何节省。从第二次备份开始，重复的百分比通常稳定，但是针对每个数据集则处于不同的级别。这主要取决于修改率/模式和备份之间的周期。这两个数字，与保持在系统中的若干完整备份组合，将对所实现的最终分值有重大影响。

<2.2.3益处>

虽然可以将去重用于任何环境，但是最理想的是用于高冗余的操作——诸如备份，该高冗余的操作需要在30至90天的周期内多次反复地复制和存储相同的数据集以供恢复目的。所描述的使用模式使该技术特别有用，其结果是将待存储的数据缩减了超过20倍(取决于许多不同的特征-详见第2.2.2节)。这样的结果能够较高程度的省钱或者能够实现之前无法实现的可能性。

在辅助存储中引入数据去重的可能的最重要的结果是该领域的巨大技术飞跃。由于限制了需要的存储空间，使得先前昂贵的基于磁盘的系统能够与磁带竞争，为辅助存储领域带来之前不可用的特征。这些特征是：立即和随机存取数据(紧急恢复)、高传输速率、一个组合式存储空间、许多备份流、廉价并且可限定的数据弹性等级、简单且快速的复制、维持了数据完整性。

此外，具有基于数据的短(即，160位)散列来验证数据的存在的可能性开拓了一种节省网络带宽的方式。可以将专用软件用于在客户端处产生散列(源端去重-见第2.2.1节)并且仅发送未存在于系统中的数据。假设散列大小低于数据大小的0.5％并且去重率为20:1，则所有数据中仅有5.5％需要通过网络来传输以便执行常规备份。这样的方法不仅使过程更快(使备份窗口更小)，而且其不需要客户端的网络允许高带宽值。当将主侧和复制本侧置于不同的州或者国家时，该特征在复制的情况下更为重要。

总体而言，数据去重技术不仅是添加至现有软件的单个特征。这是辅助存储的全新时代的开始-具有服务器和硬盘所提供的所有特征的服务器和硬盘的时代，诸如即时随机存取、极高的带宽、恒定的数据监视。由于受到网络节省复制和有竞争力的价格的支持，其为辅助存储创建了一个完整并且装备精良的解决方案。

去重系统中可用的新特征：

·高写入吞吐量(无需存储现有块)

·可用原始容量的增倍

·易于仅复制唯一的数据

·节省网络带宽(源端去重和复制)

·允许用于备份的磁盘技术、以及：

-在几秒钟内随机存取

-快速紧急恢复(同时从多个磁盘)

-多次流存取

-文件系统接口

-可配置的弹性等级

-维持的数据完整性和自愈

<2.2.4缺点和担忧>

每当以任何方式来转换数据时，用户可能会担心他们的数据的完整性。去重过程在系统中的某处查找块的相同副本，并且结果可能是一个流的数据散布在磁盘和服务器上的许多位置处。这样的节省存储空间的方式使得几乎不可能在元数据中某处没有存储确切配方(recipe)的情况下并且以与其被写入的方式完全相反的方式读取到所需要的数据。所有这些都对来自供应商的软件的质量提出了高要求，并且意味着客户要对该过程非常信任。

每个去重系统必须能够找到块并且对该块进行比较以便验证它们的身份。如之前描述的，散列函数是一种方便且有效的寻找候选以供验证的方式，但是结果是读取这样的候选以便用重新写入的块逐字节地验证其内容会使存储过程非常耗时。为了去除这种开销，业界仅依靠散列比较来确定两个块的身份。当然，理论上可以使用长度为160位或者256位的单个散列来识别大量的8KB的块，但是正如所验证的，假设抗冲突函数(即，SHA-1[25])和可以存储在系统中的块的数目，这样的冲突的概率极低，比硬件错误率小许多个数目级[66]。尽管当数据损坏出现时，也很可能是IO总线、内存或者其它硬件部件的问题。

另一个担忧与执行算法和其它需要的功能所必需的计算能力相关。如在源端去重的情况下，所述计算中的至少一些在客户端上从而使用其能力来执行，尽管在目标解决方案的情况下不需要附加的计算能力，但是在供应商在专门的硬件中提供的解决方案中需要附加计算能力。应当在购买前比较解决方案的早期阶段中计算系统所需要的能量成本。

最后，对具有许多磁盘和数十或者数百个服务器的系统进行探究，保持所有数据可存取并且不损失任何数据可能是个问题。这样的系统需要有效的分布式算法、自愈能力和合并的智能以便允许相当简便的管理。使用数千个磁盘，损坏的概率变得相当高，使得在不破坏整体可用性的情况下允许简单的磁盘/节点替换的特征变得重要。幸运的是，存在具有所有上述特征的系统能够在具有超过100个节点的配置下工作，确保甚至7.9PB的原始容量[56]。

<2.3当今市场>

根据信息存储行业协会(INSIC)对磁带技术的使用，在过去30年期间作为辅助存储最常见，最近一直在经历转型[17]。类型的系统正在从备份系统市场迈向第三层备份(用于长时间保留不常存取或者无存取的备份的最近创建的类别)、归档(针对长期存储而移动的数据)和法规遵从性数据(法规限定而保存持续时间)。所有这些用例涉及长时间保持数据的单个副本，通常完全不读取该单个副本。出于这些目的，由于价格、更长的持续时间、较少的能量成本和无去重要求，磁带可能仍然是更好的选择(见图30)。

当请求有关使用数据去重解决方案的组织时，上述趋势也得以体现。企业战略集团在2012年对超过300个受访者进行的调查显示，76％的企业已经使用或者计划使用去重解决方案(与2008年的43％相比较[30])。另一方面，存在通过市场本身发展的企业。在2011年，整个磁带市场(和其介质和机器人技术，包括存档和其它用途)最终总计为30亿美元[在下降10％之后]，而对于去重系统则为24亿美元[2](在增长43％之后)。虽然磁带市场仍然更大，但是在公司做决定时，看起来通常的20倍去重率、高写入带宽、可扩缩性、易于远程复制和快速紧急恢复被视为是重要的。

即使去重系统以剧烈的比率增长，但是它们很可能不会完全消除磁带使用。从公司收集到的数据表明[17]，针对备份，公司宁愿使用基于磁盘的系统和磁带系统二者(与2008年的53％相比较，2010年为62％)。从所有上述信息的角度来看，似乎存在以下趋势：使用磁盘和磁带模型作为用于数据保护最成功的方法，其中，基于磁盘的系统作为用于长达6个月的备份的主要部件，并且磁带被用于进行归档和需要更长保留时期的数据。

毫无疑问，由于去重，全局辅助存储的第二大跨越正在进行中(第一大跨越是：在20世纪80年代，从穿孔卡转变为磁带)。另一方面，过去几年发表的论文数目使本主题得以广泛研究。在该规模下，每个创新方法、算法或者发现可能最终对从全世界的供应商到系统管理员的每个人都有巨大的影响。即使已经提出了大量认识，但是仍然存在尚待发现的策略领域。其中一个策略领域是流碎片化，总体上作为去重和关键恢复的副作用。

<第3章流碎片化的问题>

<3.1恢复在备份系统中的角色>

即使恢复不像备份那样频繁发生，但是其不仅被用于丢失数据的情况，而且被用于将完整备份流至磁带(第三层备份)，并且将改变的数据复制到非现场。因此，甚至存在系统实际读取比写入高出20％，而平均上，即使在排除复制活动[79]时，读取负责平均备份系统中所有I/O的大约26％(平均值；9％中值)。

从备份系统恢复数据的每个尝试可能由多种原因引起。当考虑易于随机存取所有数据的基于磁盘的系统时，意外删除的文件或者存取某个文档的先前版本实际上是在短时间内处理的其中一个最简单的请求。另一方面，恢复由许多GB数据组成的完整备份是在多个小时内提供最大带宽的完全不同的问题。即使这样的场景也不一定意味着公司出现某个故障(该故障可以是将数据传输至某个其它地方)，这也应当是会首先处理得非常好的情况。恢复时间目标(RTO)作为任何备份系统规范的最重要的因素中的一个，实际上使对备份系统的数千美元投资对于绝大多数公司来说是合理的。可以将该领域的每个紧急问题视为对公司投资的备份系统和最终验证的主要测试。

当对通常的恢复过程进行分析时，可以注意到该恢复过程的特性中的一些。非常重要的一个特征是以下事实，不是每个备份都具有相同的意义，这使得恢复过程的价值不同。首先，是数据本身可能对公司来说不那么重要。其次，是采取备份时的时间和其在紧急情况下恢复的有用性。图31示出了由企业战略集团对510个受访者执行的调查的结果。毫不奇怪，最常恢复的数据是最近备份的数据。基于该结果，仅6％的恢复久于2周，并且恢复中的大多数(58％)是从最近的48小时恢复的。

总而言之，上面出现的整体情况为备份系统真实价值的验证作出了明确的目标。该目标是最新备份的恢复带宽。即使该陈述听起来很微不足道，但是它具有重大的后果，尤其是对于具有去重的备份系统，该备份系统在未来几年非常有望成为当今世界最常见的系统。

<3.1.1备份程序>

每个公司都有自己的备份策略，该备份策略应当是对数据安全和灾难恢复要求的最佳回应。其中一个最常见的策略是在周末执行所有公司数据的备份，并且每天执行较少的增量备份[79]。这通常是由每个工作日非常有限的备份窗口(备份完成的可用时间)并且在周末期间会有较大的备份窗口所引起的。当使用去重系统时，甚至可以每天执行完整备份，因为根据这样的解决方案，实际上仅存储新的和修改过的数据(其大小或多或少等于增量备份)，而非常快速地将所有其它重复数据进行确认以使该过程比常规完整备份快许多倍的备份应用。

备份策略的下一特性是在许多公司中也可以不同的保留期[18]。最初的想法是限制用于备份的空间，这在紧急恢复的情况下不太可能有帮助。通常的选择是保留一些(通常为5至30个)最近的每日备份、大约4至26个每周备份、接近12至24个每月备份和一些年备份。通常，将久于3至6个月的备份移动至所谓的存档存储，这暗示了极低的可用性可能性。在引入去重系统之后，场景正在缓慢变化。由于新技术，每个附加备份几乎没有添加新的数据到存储空间，因此，公司可以在一年中保持每日备份，仅支付相较于仅保持实际数据和修改稍多的费用(元数据)。具有这样的技术使得以极低的价格来保持高备份粒度成为可能，这可能最终有助于从所要求的日期恢复给定文档的确切状态，而不管过去的时间如何。

当着眼于单个备份过程时，人们可以注意到另一简单但非常重要的事实，该事实与数据的顺序和布置有关。每个存储系统通常接收在所谓的流中的数据：具有开始和结束的处于某种定义的、逻辑顺序的字节序列。通常，备份应用负责从待存储的文件系统或者目录生成这样的流。在通过NFS或者CIFS直接安装存储文件系统的情况下，这样的流是每个传输的文件的等效物(通常是相当大的tar存档)。具有逻辑顺序，每个流保证将顺序地并且以与其被写入的顺序相同的顺序来完成对其数据的每次存取。该假设对于所有备份系统都很重要，使它们能够实现良好的性能。从市场角度看，以非顺序方式来存取数据将使得这些系统不可用[83，66]。

<3.1.2已验证的组合：预取和缓存>

对数据的顺序存取明显有助于减少恢复性能的最大瓶颈的问题，该问题是从实际硬盘驱动器读取数据。具有最佳数据布置的事实，当涉及流行的HDD时，使得工程师能够使用简单而有效的技术，与随机或者未限定的数据存取模式相比，该技术将恢复性能提高了许多倍。

预取

在连续数据的情况下最常见并且有效的技术是以固定或者可变的较大组块的形式来将其从硬盘驱动器预取到系统内存。在这样的操作的结果中，仅一个块(例如，8KB)触发从具有大得多的组块(例如，2MB)的磁盘进行读取的用户读取请求，将所有读取到的块(2MB/8KB＝256)放置在系统内存中以供进一步使用。由于这样的方法，在顺序存取的情况下，使能许多后续读取操作从内存检索数据而无需支付磁盘存取的价格。

该算法实际上是HDD构造的结果，其使读取数据的较小部分非常低效。每个磁盘的两个主要特性是：数据存取时间和传输速率。此处，第一个特性最有问题。在开始将数据传输至系统内存之前，磁盘必须将其磁头移动至合适的磁道(寻道时间)，并且等待所需要的数据出现在磁头下(旋转时延)。整个过程非常昂贵，并且假设恒定的传输速率，这样的数据存取的数目确定了总的读取性能(见图32)。

另外，重要的是，注意磁盘技术在带宽和容量方面正在不断发展。不幸的是，同时，寻道时间和旋转数已经多年基本上保持在同一水平。实际上，因为几乎完成了该项工作，所以，希捷宣布推出其EnterpriseCapacity 3.5HDD的新版本，该新版本具有29％的更高的持续数据传输速率(226MB/s)，但是不具有读取存取时间变化[73]。这种不平等的发展使碎片化问题更加严重，因为单独存取数据花费总恢复时间中的越来越大的部分。

缓存

在从磁盘预取数据之后，将其存储到称为缓冲缓存(或者读取缓存)的专用系统内存中，其通常比实际预取大得多。其原因是在现实中缺乏理想的连续负载。在小型缓存的情况下，每个非连续中断(从磁盘上的不同位置读取)将需要在返回至先前的读取序列之后重新加载数据。由于较大大小的缓存可以不仅在所描述的场景中在一定程度上具有弹性，而且还支持不以确切的顺序来进行读取(在写入期间数据重排序的情况下)并且同时存取许多流。在重复消除备份系统的情况下，缓存的另一个功能变得相当受关注和重要。该功能可以简单地保持在相对短的时间段期间多次请求的数据块，从而允许所实现的恢复带宽的额外改善。

因为缓存的内存总是有限的，所以其需要专门的缓存逐出/替换策略。许多现有算法中的每一个都具有其自己最合适的用法。针对备份系统，最常用的策略是最近最少使用(LRU)[79、53、48、83]。在这种情况下的主要目标是首先丢弃最近最少使用的块。虽然该算法需要保持跟踪所使用的内容和何时确保去除正确的项，但是存在一些优化以使其更廉价。利用一些其它众所周知的算法——诸如本文中介绍的踪迹的最近使用和最少使用——的实验还显示利用LRU会有好得多的结果。

重要的是，针对页面替换策略(该策略在某种程度上类似)，最有效的算法实际存在并且称为：B'el'ady的最优算法[5]。为了实现最优缓存使用，该算法首先丢弃来自内存的将在未来很长一段时间不会需要的页面。不幸的是，由于通常不可能预测何时将需要该信息，所以针对大多数已知场景，该算法在实践中是不可实现的。此外，在内存中的页面与块不同，所以，将页面移动到备份系统环境中并直观易懂，但是可以带来令人关注的见解。

效率问题

即使预取/缓存算法有效地帮助实现合理的恢复带宽，但是其有时不能最佳地工作。一种情况是当存取模式实际上仅是部分地连续时。这样的模式引起可能从磁盘读取将永远不会使用的大量数据，并且浪费在实际读取操作期间的时间和内存中的空间，这有效地使缓存甚至比保留的实际内存少几倍。

另一问题与多次加载到缓存的块有关。这样的场景可能发生在块在其被使用之前从缓存内存逐出(太小的缓存内存或者过于随机存取)或者即使该块已经被使用而还被需要被使用超过一次(内部流复制)的情况下。当涉及具有去重的备份系统时，特别是第二个场景在我已经探索的踪迹中出人意料地密集，即使在一个连续的数据流内。

<3.2具有重复消除的系统中的碎片化问题>

一般而言，将碎片化定义为被分解成碎片的状态。出于本文之目的，我们专注于所备份的数据的连续流和将其存储在具有重复消除的系统中的磁盘驱动器上的方式。因为相较于理论观点，我们通常更关注实用的观点，所以针对碎片化，与在完美的连续数据布置的情况下需要的I/O数目相比较，我们仅考虑在使用上述的预取/缓存算法时需要额外的I/O操作(磁盘存取)的这样的块重排序。

具有重复消除的备份系统在对数据存储空间的使用上与没有这样的特征的备份系统有很大不同。从外部观点来看，仍然可以将每个备份过程视为连续的，但是当涉及进行了去重的数据时，仅一些过程最终会到达硬盘驱动器。不幸的是，这样的写入模式高度增加了在3.1.2章节中描述的导致碎片化的预取/缓冲算法中的低效率问题。从其设计的去重概念最终将总是施行将两个块的存储作为在磁盘上的相邻块——该相邻块实际上在实际逻辑流中彼此相距许多MB来放置或者与两个逻辑连续块相反进行存储。为节省存储空间而需要的这样的数据放置为研究人员识别并且解决出现的新问题打开了一个新的领域。

一般而言，存在三种碎片化问题，每个碎片化问题由数据去重的不同方面导致，其中，对最终恢复带宽有完全单独的影响(见图33)。可以在以下章节中找到对每个区域的详细描述和分析。

<1.2.3内部流碎片化>

实验显示，与没有该特征的系统相比，在整个系统中只有一个单个备份具有去重可能已经导致其恢复性能下降。这样的现象被称为内部流碎片化，并且是由在单个流中多次出现的完全相同的块所导致的。

图34示出了初始备份的一部分(从逻辑块偏移402至438)。在提出的序列中，人们可以注意到存储在盘上的与其它位置不同的位置中的块(i'5、i'1、i'76等)，因为它们是已经存储在相同流的先前部分中的重复。这样的块的问题在于，为了读取它们，磁盘驱动器必须将其磁头移动至与当前读取前端(i'279与i'304之间)不同的位置，这需要额外的I/O。此外，算法通常会尝试读取数据的完全预取，将其放入缓存。这浪费了分配的内存，因为在许多情况下，将仅使用这样的块中的一小部分。当涉及最终恢复带宽时，整个过程可能非常昂贵。

注意，块i'6和i'129不导致附加磁盘存取，即使它们不在主序列中(从i'279到i'304)。这是由于以下事实：由于先前读取的块i'5和i'128不需要额外的I/O，因此在进行读取时，这些块将存在于缓存内存中。此外，人们可以注意到名为i'5的两个块，而只有第一个被标记为导致磁盘存取。其简单地假设因为仅先于27个块读取块i'5，所以在恢复其第二个副本期间，该块i'5仍然会存在于缓存中。

已经看过图34并且假设4个块的示例预取大小和100个块的缓存(因为其目前适配流的25％而相当大)，我们可以使两个令人关注的情况所需要的I/O的数目的差异可视化。当将流的示出部分存储在无去重的系统中时，我们需要10次I/O(＝10×预取大小4)来读取整个部分。其原因是对37个块(从402到438)的连续读取，因为在这样的系统中，逻辑地址与物理地址完全相同。另一方面，当使用去重时，我们需要7次I/O来读取从i’279到i’304的连续数据(26个块)和8次额外的I/O来读取重复数据(见图34)。当比较两个结果时，描述的场景之间的差异处于50％的水平(10对15次I/O)，这意味着具有去重的系统恢复相同备份数据的时间多一半。注意，我们已经假设了适度大的缓存大小，否则我们可能需要重新考虑添加额外的I/O以读取第二个i'5块(逻辑偏移431)，因为可能已经同时从缓存中逐出了该第二个i'5块(读取偏移404与431之间)。

幸运的是，可以巧妙地扭转内部重复块的出现以减少而不是增加流恢复所需要的总时间。我们假设从最开始(从逻辑偏移1、2、3...开始)读取相同的初始备份，但是具有无限制缓存。在这样的情况下，在实现块402(磁盘位置：i'279)之后，标记为重复的所有块将已经存在于内存中。因此，当请求存在于图34中的部分时，无去重的系统中将仅需要7次I/O而不是的原始10次，最终恢复时间减少30％。

一般而言，即使预期重复还可以在一个流内出现，但是令人惊讶的事实是这样的外观的规模和其对实验中的恢复带宽的负面影响。更好的消息是或多或少恒定数目的内部重复块和对每个备份的类似的影响，而不管之前执行的备份的时间和数目如何。另一方面，重要的事实是观察无限制缓存大小的影响，这将是进一步的分析并且启发由有限先期知识支持的替选缓存逐出策略的提出(见第4章)。

<1.2.2版本间碎片化>

因为定期执行备份(每日/每周/每月[18])，所以可以在相同数据集的各个版本中找到一个逻辑流的每个片。根据在一个备份周期内修改的数据量(通常为非常小的百分比)，每个这样的版本都与先前的版本不同，这使相同数据集的后续版本非常类似。

每个具有去重的备份系统将发现重复的块并且最终仅存储已改变的块，而最受欢迎的在线解决方案(见与第2.2.1章节中的离线版本的比较)将始终将所有修改过的/新的块一起放置在当前未被占据的空间中的一些连续存储区域中。不幸的是，在数十或者数百次备份之后，这样的数据布置导致最新备份的数据分散在整个存储空间。

图35示出了存储在具有在线去重的系统中的样本备份集的十个版本。每个版本被存储在磁盘上的一个连续片段中，但是因为初始版本存储其所有数据，所以版本1到版本9仅添加不存在于先前的备份中的数据(删除所有重复块并且不将其存储在磁盘上)。因此，可以在初始章节1至9中的每一个中的磁盘上找到属于逻辑备份9的块。

在图36中可视化了备份9的前38个块的恢复过程。假设预取大小为4个块并且甚至无限制的缓存内存，读取在示出的示例中的所有块需要21次I/O(见标记的块)，而在所有数据总是仅被连续地放置的系统中10次I/O(38除以预取大小)是足够的。最后，超过两倍的恢复时间是在所描述的场景中的碎片化的实际成本。

将以这样的方式来实现碎片化称为版本间碎片化。此处独特的事实是，当人们开始使用该系统时，不存在这样的类型的碎片化，并且这种碎片化在以下备份期间以对于每个数据集和使用模式非常唯一的速率增加。因为该过程在共同备份周期期间是不可见的，所以当恢复必要时，通常会出现该过程，这可以揭开比预期的恢复带宽低几倍的恢复带宽的问题。在恢复是紧急问题的情况下，这样的发现可能具有非常昂贵的后果。

至于版本间碎片化，两个事实似乎使问题的核心清楚地可视化。第一个核心是变化的特性，该特性是缓慢并且随着备份的数目而增加，而另一核心是关于在章节3.1中描述的恢复的数据的典型存期的知识(见图31)。考虑到最新近的备份是最可能要恢复的，问题看起来非常严重的，但是另一方面，收集的信息在尝试解决该问题时给出令人关注的见解。

<3.2.3全局碎片化>

全局碎片化实际上与内部碎片化非常类似。唯一但显著的差异是有问题的重复不来自相同流的较早部分，而是来自完全不相关的流的较早部分。这是由于以下事实：随着内部碎片化，问题由流中的第二以及进一步的块的出现所导致，这允许我们通过将已经恢复的块保持在足够长的缓存中来抵消其消极结果。在全局碎片化的情况下，问题出现，其中已经出现第一个块(进一步的块应当适格于内部碎片化)，并且因为该块在当前备份集的外面，所以可以在整个系统内的几乎任何位置中找到它。

我已经对五个独立的数据集执行了简单的实验以便验证全局重复块的数目和全局碎片化对恢复性能的影响。针对每个数据集，选择第一备份作为数据集代表。通过存储所有代表但不存储测试的被加载为最后一个代表的被测试代表来准备备份系统。通过将重复块的数目和带宽与当这样的备份被存储为系统中唯一的备份的场景相比较，我们可以使问题的规模可视化。

图37中的结果实际上示出了存在于其它独立数据集(在0.01％与1.47％之间)中的非常少量的全局重复块。即使结果表明对恢复带宽相对小的影响(在0.06％和8.91％之间)，但是实际数字可能不同并且将很可能随着独立数据集的数目和存储在系统中的唯一数据的总大小而缓慢增加。

可以确保来消除全局碎片化的是对能够潜在地具有共同块的所有数据——诸如不同员工或者虚拟机系统分区镜像的邮件/家庭备份——一起进行备份(在一个流中)。不幸的是，这样的方法仅在存在一起恢复这些数据的概率时才有意义，否则它不会有帮助。所描述的修改的目标是将全局碎片化转换成更容易处理的内部碎片化。

另一方面，如测试结果(图37)表明，独立数据集仅共享非常少量的数据，这有时导致可观量的碎片化(见问题库)。为了防止这样的场景，人们可以决定不对其它数据集进行去重，而只对当前数据集的先前版本进行去重。这样的方法将以所存储的通常较小的附加块为代价来消除全局碎片化。

当假设没有允许存储的重复块时，全局碎片化肯定是最有问题和复杂的，既要分析也要解决。对当前系统中的任何一个来消除重复数据块使我们的备份以某种方式依赖于另一完全不相关的或者可能更不相关的系统。即使每个共同块的一些全局最佳位置存在，其计算通常也是复杂的，并且即使发现了该全局最佳位置，所涉及的备份中的至少一些无论如何也将经历碎片化。此外，实际上无法验证这样的因素的影响，因为给定的踪迹中的每一个将基于存在于系统中的其它数据而表现不同。

所描述的复杂性——通常是在备份流中的少量全局重复块和对恢复性能的相当恒定的影响(具有恒定数目的数据集)导致其它问题的高得多的优先级：版本间碎片化和内部流碎片化。考虑到这一点并且相当困难或者甚至不可能验证的全局碎片化的特性，我已经决定不在本文中进一步对该问题进行分析。

<3.2.4可扩缩性问题>

当要检查大型去重备份系统时，必须考虑整个新的视角。具有数十或者数百个服务器和甚至数千个硬盘，所有问题趋于另一水平。一方面，存在用于处置请求并且掩盖潜在问题的硬件，但是另一方面，可扩缩性目标需要对系统能力连同其大小一起进行缩放。

通常，当从大型系统恢复备份流时，该过程涉及许多磁盘。由于擦除编码[80]或者RAID通常存在，所以甚至将每个单个块切割成较小的片段，并且然后将其放置在许多硬盘驱动器上。更多的磁盘意味着更好的弹性和更高的潜在单流性能，但是不幸的是，伴随碎片化问题的倍增以及对有时更昂贵的对单个块的存取。假设一个连续流由10个磁盘保持，为了读取该连续流并且保持接近最佳带宽(即，一个磁盘接近1750MB/s而不是175MB/s[71])，系统应当从每个磁盘预取大约2MB的数据，最终以20MB的总预取结束(见[48]中的类似观察)。因为这样大的预取具有高得多的无效可能性，所以在实践中，大多数系统使用同意次优选择并且限制最大可能的性能的小得多的缓冲区[48]。较大的总预取还意味着通过预取不需要的数据和较高的最大碎片来浪费缓存内存的较高概率，因此需要大几倍的缓存。最后但并非最不重要的，在一个磁盘驱动器的情况下，有用数据的最小大小是2MB预取中的8KB(0.4％)，而可扩展的解决方案有时甚至是20MB中的8KB(0.04％)，显著增加了每个随机读取的成本。注意，对于配置有比去重块大小更大的条带大小(stripe size)的RAID，可以不将一个块切割成许多片段。尽管如此，假设典型的条带大小为4至128KB以及我们从不读取小于预取大小(2至20MB)的数据的事实，无论如何将使用所有驱动器，这使得用户处于与擦除经编码的场景类似的场景。

一般而言，通过具有更多转轴来确保良好带宽容易得多，但是对于大型系统，相较于单个磁盘驱动器的尚可的单流性能人们应当期望更多。在紧急情况下，人们应当期望对通常每天/每周进行备份的多个流的恢复过程，这表明将读取的可扩缩性保持在与写入相同的水平，其通常在一个或者非常有限数目的磁盘位置中执行。无论如何，即使在恢复单个流的最简单的场景下，也需要利用最小量的能力和系统内存而获得最大性能。

<3.3问题量级>

为了使碎片化问题的真正规模可视化，我已经对从商业系统HYDRAstor的客户收集到的六个不同数据集执行了模拟。可以在章节6.1中找到对所有数据集和实验方法的详细描述。

<3.3.1不同种类的碎片化对最新备份的影响>

在图38中，最上面的线与通过具有给定的缓存内存大小的最新备份可实现的并且采用B'el'ady的缓存逐出策略(称为采用的B'el'ady的缓存)的恢复带宽相对应，尽管该线在从页面移动至块时不是最优的，但是非常好地陈述了可实现的性能水平(有关算法的细节见第3.1.2章节，并且对于在预取块的情况下对其最优性的缺乏的讨论见第8.2.2章节)。其它线是使用真实备份系统和最常见的LRU缓存逐出策略的模拟结果。而中间的线示出了仅最新备份存在于整个系统中的数目，因此示出了内部流碎片化的影响，但是底部的线表示在存储了来自数据集的所有备份之后的最新备份带宽，不过也包括版本间碎片化。

针对不同的缓存大小收集结果并且将该结果可视化为没有去重的系统实现的恢复带宽的百分比(假设连续数据位置和缓存大小仅适配一个预取)。注意，使用无限制的内存，内部碎片化不存在(仅版本间碎片化是可见的)，如在对于任何重复块的读取请求的情况下，算法将总是直接从内存接收重复块。此外，只要在备份流中不存在版本间碎片化和数据重排序，就可以将具有这样的无限制的缓存的恢复带宽视为最大的带宽。

从一些内存级别开始，人们可以很容易地注意到每个数据集的高最大带宽级别——甚至高于100％。该现象实际上是在第3.2.1章节中描述的内部流重复块的积极影响(读取已经在内存中的重复数据)。即使针对一些数据集，这样的值对于实际的缓存大小(512MB及以下)也是可能的，但是在实践中，结果显示性能劣化高达70％(见：邮件和问题库(Mail and IssueRepository)图表)。此外，在添加版本间碎片化的影响(高达50％的劣化)时，最终结果可以达到比最优水平(IssueRepository)低甚至81％，该结果比无去重的系统的水平低75％。

一般而言，很难对版本间或者内部流碎片化的重要性进行议论。即使它们二者合计为最新备份的恢复性能劣化，但是它们的起源和特性大不相同。而且，它们中的每一个的影响高度取决于被用于测量的数据集。更重要的是，版本间碎片化随每个备份而增加，这使测量的时刻非常重要。

<3.3.2时间上的碎片化>

当涉及具有在线重复消除的备份系统时，时间或者所执行的备份的实际数目的视角非常重要。图39示出了在每个所执行的备份之后的碎片化问题。顶部的线表示可利用无限制的缓存(消除内部流碎片化)和无版本间碎片化来实现的带宽以示出每个数据集中的每个备份可实现的最大性能水平。所有其它的线包括两个种类的碎片化。

不幸的是，虽然未超过50个备份，但是很难显示该问题的影响，该影响可以在许多年的定期备份后得以最好地验证。然而，一些近似值由Lillibridge等人[53]通过480个备份的合成数据集给出，该合成数据集覆盖2年的时期并且示出在没有使用去碎片化时的高达44倍的下降。尽管该合成数据是由惠普存储部门(HP Storage Division)基于涉及高碎片化的客户来生成的，但是其仍然良好地使问题可视化。

如我的实验显示(见图40)，内部流碎片化的水平对于一个集合内的大多数备份而言或多或少是稳定的，并且通常保持在第一初始备份的水平。因此，每个附加备份的减少通常是由版本间碎片化导致的。因为无论缓存的大小如何，这样的性能下降——被表示为初始备份的百分比——是类似的，所以在查看图39中的两条最上面的线时，可以容易地注意到问题的实际规模。它们二者都具有无限制的内存(该无限制的内存使内部流碎片化的影响无效)，但是只有较上面的那条线不包括版本间碎片化。出于图表的清楚起见，省略了每个缓存大小和无版本间碎片化的线，但是在图38上呈现了每个因素对最新备份的详细影响。

<3.3.3缓存大小对恢复时间的影响>

如在图40和3.5中示出的，可以将缓存视为被用于应对内部流碎片化的武器。尽管其发挥了作用(特别是当无限制的内存可用时)，但是价格非常高。例如，当利用32MB的缓存内存来启动DevelopmentProject时，需要使用16倍的更多的内存(512MB)才使恢复带宽增加一倍并且对于无重复的系统仍然在100％以下。类似的，利用IssueRepository来实现相同的结果，所需要的内存为多出64倍(2048MB)。此外，当虑及现代备份系统同时处置许多备份流时，必须再次将所需要的内存乘以许多倍，使总系统需求巨大。

此外，即使增加内存确实提高了通常备份的性能，但是接收到的帮助是非常无效的。因为采用B'el'ady的缓存的算法显示(图38中的总顶部线)，在大多数情况下，仅具有128MB或者256MB的缓存内存备份应当能够允许具有接近最大可能带宽的恢复，该最大可能带宽是比使用传统缓存使用(LRU)实现的带宽高20％(通用文件服务器256MB)到519％(问题库256MB)，并且通常高于非重复系统带宽的水平。大不相同的唯一数据集是邮件，其中，内部重复模式甚至使得采用的B'el'ady的缓存无法实现具有合理的内存量的非重复带宽水平。

另一方面，关于版本间碎片化，附加内存似乎没有很大帮助(图38)。无论虑缓存大小如何，对这种碎片化方面导致的增加恢复时间的影响是类似的，并且对于最短集合(Wiki、开发项目、通用文件服务器)等于13％至20％，对于邮件和用户目录为34％至46％，并且对于在仅7次备份之后的最碎片化的问题库，甚至高达91％至171％。

对在一个数据集内使用不同的缓存大小的模拟结果仅示出了内存大小对实际实现的带宽的适度影响，但是也指示了这样的观察的原因。虽然版本间碎片化问题似乎或多或少是与内存无关的，但是与内部碎片化相联系的第二个问题仅由常见的最近最少使用缓存逐出策略所达到的低内存有效性导致。正如利用采用的B'el'ady的缓存的实验显示的(见图38)，该问题的潜在解决方案可以通过使用甚至小8倍的内存量来提供较高的恢复带宽(在所有数据集中，利用所采用的B'el'ady的缓存的具有128MB优于利用LRU的1024MB)。

<3.4用于在恢复期间减少碎片化的消极影响的选择>

碎片化是去重的自然副产品(或者浪费)。有可能通过将每个备份保留在单独的连续磁盘空间中而没有在备份之间的干扰来完全消除碎片化，然而，在这样的情况下，将不存在去重。

用于实际上消除碎片化对恢复性能的影响的另一方法是使用大的所预期的块大小来进行去重。在这样的情况下，当碎片化发生时，将不会很大地降低恢复速度，因为寻道时间是由读取块数据所需要的时间来支配的。例如，具有16MB的预期块大小，175MB/s的读取磁盘带宽和12.67ms的读取存取时间[71]，对每个块的读取的寻求将增加小于14％的恢复时间。然而，用于去重的最佳块大小在4KB与16KB之间变化，其取决于特定的数据模式和存储系统特性(我们需要在计算去重的有效性时包括块元数据[69])。利用大得多的块，去重变得非常无效，因此使用这样大的块不是一个可行的选择[54、69、42]。

一种令人关注的解决方案将是使用缩减去重来应对碎片化。在该方法中，每当在备份期间，一些当前写入的块在磁盘上相距很远时，无论现有的副本如何，都可以将其简单地存储在磁盘上。不幸的是，如解决方案中的一个示出[48]，该路径导致较低的重复率，特别是当朝着合理的恢复结果移动时。令人关注的权衡将是以这种方式但使用将节省完全去重的其它技术来应对全局碎片化(因为它通常是由小数目的重复导致的)，以解决版本间和内部流碎片化。

给定的备份系统通常由许多服务器和磁盘组成，它们还可以被用于加速恢复。如果来自一个驱动器的性能处于由不具有去重的系统所实现的25％的水平，则可以使用四个(或者更多个)磁盘来达到期望的级别(连同预取和缓存加倍以及所有结果)。唯一必要的修改将是在所选择数目的驱动器之间划分单个流，无论如何都通常是这种情况(例如，RAID)。虽然该提议意在掩盖问题而非解决问题，但是每当有足够数目的未充分利用的设备可用时，它就会起作用。

最后，针对称为离线去重的版本间碎片化的问题，还有一个潜在的良好解决方案(详见第2.2.1章节)。在该方法中，因为最新的备份始终被存储为单个连续流，所以恢复性能是最优的(假设无内部重复)。不幸的是，这种去重概念的问题的数目导致这样的解决方案在市场上存在的百分比非常小。

上面呈现的选择尽管可能并且有时甚至非常容易引入，但是需要相当大量的附加资源或者提出不容易接受的权衡(即，以去重有效性为代价来恢复带宽)。另一方面，仅通过查看备份和恢复过程的细节，可以找到许多令人关注的特性。以专门的方式来使用它们实际上可以仅以最小的成本来解决问题，并且出人意料地达到之前不可实现的恢复带宽水平，有时甚至高于由无去重的备份系统提供的带宽水平。

<第4章具有有限的先期知识以减少内部碎片化的影响的缓存>

如在先前的章节中陈述的，在具有重复消除的系统中通常低的恢复带宽的主要原因中的一个是内部流碎片化。当对每个缓存大小的测试结果进行分析时(见图38)，可以在与利用LRU缓存的常见解决方案相比较时，甚至在仅单个备份存在于备份系统中时(无版本间碎片化)注意到利用所采用的B'el'ady的缓存实现的高得多的恢复带宽。即使该结果依赖于数据集而大不相同，但是所有缓存大小的平均增加高于80％，而对于具有256MB缓存大小的示例，该值从对于通用文件服务器和Wiki的7％和25％直到对于问题库和邮件的160％和197％不等。

在以上结果中经可视化的实际问题是缓存内存的低效率使用。由于由LRU递送的预测的低质量，所以在实际使用(或者重用)块之前，通常将该块从缓存逐出，而同时许多根本不需要的块占据内存。这在具有去重的备份系统中尤其如此，其中相同块的许多副本经常出现在单个流中(更多细节见图51)。

在本章中，我想呈现具有有限的先期知识的缓存逐出策略的算法，该算法的目的是通过仅保留将在不久的将来参考的块来减轻内部流碎片化的后果。所提出的解决方案的副作用大体上也是更有效的缓存使用，其在被用于具有版本间碎片化的流时也提供益处。

<4.1最终解决方案的所期望的属性>

为了成功地将LRU替换为缓存替换策略，新的解决方案应当：

·提供接近利用所采用的B'el'ady的缓存来实现的恢复带宽的恢复带宽(并且当然显著地高于LRU)，

·不需要待存储的附加数据(应当保持最高的去重有效性)，

·如果恢复算法有任何修改，则仅强制执行少量，

·不需要恢复算法以外的任何改变，

·不需要很多的附加资源，诸如磁盘带宽、转轴和处理能力。

·如果需要，在解决权衡时提供一系列选择。

<4.2想法>

备份应用通常在将每个数据集存储在备份系统中之前将每个数据集压缩成一个大的(数十或者数百GB[79])逻辑流。许多读取[48]和去重[83]算法已经依赖于这样的备份策略，并且倾向于优化流存取的路径，这在备份系统中实际上非常常见。在我的想法中，我想在恢复过程期间进一步优化该众所周知的属性。

因为内部流碎片化的问题似乎经常出现，所以任何先期知识都能够非常有用以便在内存中仅保留将在最近的未来重现的那些块。该想法本身存在于B'el'ady的算法中[5]，但是使其通常无用的主要问题是难以或者甚至不可能得到这样的信息。幸运的是，在备份系统中，该特性是不同的，因为备份通常非常大，并且以与写入它们的顺序相同的顺序来对其进行存取。当开始恢复时，通常可以发现整个恢复配方，这意味着具有对有关将来请求的块的实际上无限的知识的存取。

即使使用所有转发地址的想法是吸引人的，但是在现实中不必要，因为它们将占用宝贵的内存，否则该内存可以被用于实际缓存(保留数据)。我的实验显示，只要具有有限量的这样的先期知识就足以递送良好的恢复性能，这通常接近于所采用的B'el'ady的缓存(该缓存具有无限的先期知识)的结果。

<4.3系统支持>

为了实现有限的先期知识缓存，我假设备份系统支持以下能力：

·用于具有完全相同的内容的所有块的一个地址：具有相同内容的块还应当具有相同地址。在备份系统的情况下，通过内容可寻址能力来确保该属性[66]；

·具有单个流识别符的整个备份恢复：被递送至系统的单个识别符应当足以读取整个备份；

·提前预取元数据的能力：系统应当能够在检索实际数据之前首先读取限定数目的元数据。缓存逐出策略将需要这样的元数据以确保更好的内存使用。

具有去重的大多数系统已经支持内容可寻址能力[83、23]，并且提供用于读取整个流的机制，例如，给定文件路径作为识别符。而且，每次恢复都需要元数据，从系统中的专门的位置(通常与数据分离)逐渐读取该元数据以便接收完整配方和实际数据块的地址。可以容易地引入小重组以便在开始流恢复之前读取更多这样的元数据。因此，可以将在下一章节中描述的算法视为通用的并且可适用于具有去重的广泛的系统。

<4.4算法细节>

<4.4.1系统恢复算法>

从系统级别来看，通过接收流识别符来开始对流的恢复(见图41)。即使这样的操作解锁对所需要的所有元数据的存取，但是通常仅读取一些小的元数据以便不占用太多的内存。基于此，发送读取具有专门的地址的块的请求。当恢复继续时，读取附加元数据并且发出更多的请求。整个过程非常流畅以便提供恒定负载，从而充分利用系统及其资源。

所提出的解决方案的基本想法是使用已经在系统中的信息。因为具有有关将来要读取的块的知识对于缓存策略来说可以是非常有用的，所以算法应当能够读取一些合理量的这样的先期知识。

<4.4.2磁盘恢复过程>

在磁盘级别处，当涉及数据存储时，使用标准预取和缓存算法，但是利用修改过的缓存逐出策略(见图42)。由于接收到的转发信息，所以可以创建具有有限的先期知识的专门的智囊(oracle)。关于下一个块的出现的其的信息有助于确保在缓存中接近最优的内存分配。

每当在本论文中使用名称——缓存时，其总是指代保留实际数据的内存，对于所有缓存算法是共同的(在上述图上的数据缓存区域)。因此，其不包括特定解决方案所需要的附加内存。LRU缓存、先期知识缓存和其它类似名称被用于指代利用与缓存逐出策略相对应的整个算法。

具有有限的先期知识的智囊

将智囊设计为保持所有已知的处于前面但未读取的块的识别符连同它们出现在流中的块位置的经排序列表的映射(见图43)。利用先期信息的更新将在块的识别符不存在的情况下对其添加)，并且在其列表的后面推动适当的块位置。在必要时，结构可以为给定块返回其将需要的最近的未来位置，或者通过从下一个块出现的列表中去除其最靠近的(当前)位置来更新最新近读取的块。利用附加数据，具有有限的先期知识的智囊需要与保持缓存数据的专用内存不同的专用内存。针对根据先期知识的总量的每个块地址，块识别符和其在流中的位置二者都是必需的。幸运的是，可以将两者的大小限制为仅使用实际缓存所需要的内存的一部分。

可以由块的地址来识别在系统中的每个块。在去重备份系统中，这样的地址通常基于块内容，并且通过使用散列函数——诸如160位SHA1来对其进行计算。将这样的原始地址(散列)大小设计为确保极低的冲突概率以便不将两个不同的块假设为完全相同的块(详见第2.2.4章节)。幸运的是，在智囊结构的情况下，这样的信息不需要那么精确。首先，即使当一些散列冲突出现时，唯一发生的事情是在内存中保留单个块，这实际上在将来是不需要的(并且当预期的发生事件未发生时，将容易检测到和去除该单个块)。其次，利用有限的先期知识，算法还限制整个存储系统的子集以便找到冲突(即，限制到几个GB)。为了设置示例，在大约2百万个块(＝16GB数据，假设8KB的块大小)内存在1百万到1千万个散列冲突，同时具有64位(8字节)散列函数并且假设其均匀分布(下面的数学公式1)。这得出以下结论：64位识别符足够好以用于提供需要的功能。

[数学公式1]

关于在流中的块位置的确切信息在算法中也不是必需的。因为算法的唯一目的是大致比较在流的相当大的部分(即，几个GB)上的块位置，所以足以将流划分成段并且仅保留该减少的信息以便节省内存。这样的段可以覆盖例如，8MB(任意数)并且可以通过其编号来从流的开始处连续地对其进行识别。因为期望在使用所有数字的情况下保持段识别符受限(即，2字节)，所以可以执行重新编号操作以从存储在智囊中的所有编号中减去当前段的编号。在我们的示例中，这样的操作尽管在内存中执行很便宜，但是将对存储在单个流中的每8MB×64K(2字节)-8GB(属于先期知识)＝504GB的数据执行一次(根据Wallace等人的对超过10000个系统的备份工作负载分析，这实际上只在百分之几的案例中发生[79])。.

缓存的块位置

通常将先期知识缓存组织为具有作为密钥的块地址和作为值的数据的标准映射。与LRU的唯一区别是保留的信息的种类(见图44)。代替存储最近最少使用的块(LRU优先级队列)的列表，保留最近出现的块的有序列表-FK缓存优先级队列(具有二进制搜索的能力以防添加具有新位置的块)。除了存储下一个块出现信息而不是最近使用的事实之外，所有操作——诸如更新或者添加块——都与对LRU结构的操作非常类似。

逐出策略

图45和图46示出了在两种情况下的块恢复和缓存逐出策略的示例。第一个示例：当在缓存中找到块时，以及第二个示例：当必须从磁盘恢复块时。在前一种情况下，所执行的唯一操作是在缓存和智囊结构中实际更新所恢复的块。后一种情况要更复杂，并且还包括缓存逐出过程。一般而言，缓存逐出过程由以下步骤组成：

·从磁盘读取块以对与其预取一起缓存(利用有关由智囊提供的下一段出现的信息来更新缓存)

·更新缓存优先级队列，使通过下一次出现的具有恢复的块的段的方式来对块进行排序。

·利用下一次出现的最长时间(最高的段编号)来去除超过最大缓存大小的块。

·继续按照与通过缓存执行恢复时的方式相同的方式来更新结构(4.5)。

在对于最新近预取的块在智囊中不存在下一次出现的已知段并且在缓存内存中仍然剩下一些空间的情况下，可以做出几个选择。我们可以在缓存中保留这样的块中的一些(例如，通过指派人工的并且较大的段编号并且使用LRU或用于逐出它们的其它算法)，或者在用于不同结构的动态内存分配的情况下是可能的情况下，释放内存以用于其它目的。因为我的实验显示第一个选择未提供明显的性能增益，所以必要时更好的选择将是针对其它系统操作(诸如恢复、写入和后台计算)使用附加内存或者动态增加智囊大小，这将引起在直到有效率地使用所有可用的内存之前提供更多的先期信息。

上面呈现的算法与所采用的B'el'ady的缓存非常类似。实际上，该算法在直到由先期知识指示的块100％利用缓存内存之前都完全相同地运行。任何较低的利用率指示比所采用的B'el'ady的缓存更糟糕的运行状况。这样的场景的原因总是在于先期知识大小和个体流的特性的限制(在先期知识区域外的重复块)。

<4.4.3内存需求>

因为按照与具有LRU算法的缓存非常类似的方式来构建在利用先期知识的算法中的缓存本身，所以其内存需求不发生改变。然而，利用其先期知识的智囊将需要单独的和专用的内存。另一需求可以是在其作为先期知识被接收之后但在其实际被用于恢复数据之前等待被恢复的所有块地址的附加列表。因为先期知识大小可以覆盖许多千兆字节，所以在地址被用于恢复数据之前，可能花费许多秒(我假设递送了地址以便在尽可能快地执行恢复的同时填充先期知识)，这意味着其需要专用内存。在第4.4.4章节中详细描述的替选方法可以是不占用附加内存，但是将元数据恢复两次：一次是用于先期知识，以及第二次是用于恢复本身。无论使用哪种解决方案，都应当将适当的内存大小包括在为恢复缓存所指派的总内存中。

可以如下来计算所需要的附加内存的具体量。在智囊中的每个条目最多等于一个短散列(8字节)和一个段编号条目(2字节)。为了详细说明，我们还需要包括结构开销。因为标准映射需要保留昂贵的指针(每个指针8字节，而我们每个条目仅保留10字节)，所以具有闭散列的散列表在此处是更好的选择，可能以内存内存取时间为代价。尽管如此，针对在该情况下可接受的结果，相较于请求的内存，分配的内存应当至少高出30％[37]，该结果最终为每个条目大约13字节。连同在20字节大小(160位，假设SHA-1)的等待列表中的全地址，总共33字节是具有一个块(8KB)先期知识的成本，这进一步意味着每1GB数据4.12MB。为了最佳结果，需要几GB的先期知识(其具体取决于每个确切的数据集特性)。

<4.4.4讨论>

替选解决方案

重要的观察是，仅保留将来要读取的数据的地址的列表已经消耗了所需要的附加内存的三分之二(每个块保留33字节中的20字节)。下面呈现了用以最小化这种影响的值得考虑的一个想法。

为了不保留分配的附加内存，最简单的方法是从系统再次读取地址。在这样的情况下，将存在对元数据的两个流存取：一个是用于向智囊提供适当的信息，并且另一个是请求待恢复的具体块地址。给定块地址的大小是每8KB块20字节，整个操作将需要读取比利用原始解决方案多0.256％的数据，每个1GB的先期知识仅留下大约1.62MB的内存的小需求(而不是4.12MB)。

该解决方案听起来很吸引人，特别是在只有少量内存可用的情况下。确切的选择将肯定需要对给定系统和两种方法的其它可能结果进行详细分析。

不同的元数据读取顺序的影响

因为将利用提出的算法来大大的修改元数据恢复的模式，所以出现了其对恢复性能的影响问题。有关该主题的讨论总体上是困难的，因为它需要给定系统和其元数据恢复过程的详细知识。幸运的是，因为元数据通常只是待恢复的所有数据中的一小部分(0.256％，其中每个8KB为20字节)，所以即使再次全部读取它们也不应当产生大量额外的工作。而且，当考虑到具有每个块超过100字节的高元数据开销的系统[69]时，在相同场景中的总恢复带宽劣化将仍然低于1.5％，该劣化应当几乎不被注意。

<4.5权衡>

在利用先期知识的智能缓存领域中的主要权衡是关于专用于标准缓存和先期知识的内存大小。取决于数据集特性和可用内存总量，只有非常少量的先期知识已经可以在一些情况下确保有效的缓存使用，而在其它情况下，即使以小得多的缓存大小为代价，非常大的先期信息也是好得多的选择。

该问题的最佳解决方案将是不在缓存与智囊之间声明任何硬划分。由于这样的方法，系统将能够在缓存内存未被充分利用的情况下扩展未来知识或者反之减少未来知识。尽管所描述的场景是吸引人的，但是它复杂得多并且需要详细的测试，特别是在分布式通信可能有问题的真实存储系统的情况下。这些担忧使我提供了具有硬划分的版本，为未来的工作保留该解决方案的细节。

另一种权衡与段的大小有关。由于为了节省内存，不保留下一个块出现的精确位置，所以可以不按照所期望的顺序来进行某些逐出。当许多块位于单个段中并且要逐出一个块时，这样的场景可能发生。幸运的是，这样的事件不会过多影响性能，因为重排序只会在具有到下一次发生的最长时间的块(最不重要的块)内发生。而且，所实现的性能永远不会低于相同场景中的性能，但是缓存内存减小了单个段的大小。在256MB缓存和8MB段大小的典型场景中，性能永远不会比具有248MB缓存和有关每个块位置的确切知识的性能差。

<第5章用于减少版本间碎片化的影响的基于内容的重写算法>

在第3.3.2章节中呈现的实验示出了由在线重复消除导致的版本间碎片化的负面影响。即使值在一些情况下似乎不是很重要(在通用文件服务器、Wiki和开发项目的情况下，在7至14次备份之后恢复带宽减少大约12％至17％)，在那些数据集中的备份的数目相对较少的事实和利用较长的数据集增加由实验支持的时间的问题的可见趋势(在邮件和用户目录的情况下，在22至50次备份之后大约减少19％至36％)表明在现实生活的使用中的潜在高度影响，其中为一个数据集创建的备份的数目每年从50个增长到超过300个。此外，问题库数据集指出，存在仅执行了7个备份就可能已经付出了潜在恢复带宽的50％的情况。另一方面，我的观察在Nam等人的独立数据集和Lillibridge等人的较大数据集(超过90个备份)上得到证实。

在本章中，我想提出基于上下文的重写算法(CBR)，该算法通过改变块的位置以反映当前的流式存取(streaming access)模式来处置版本间碎片化的问题，并且因此，提供更有效的预取和缓存使用。

<5.1最终解决方案的期望属性>

该问题需要对去重系统的其它重要度量没有负面影响的解决方案。这样的解决方案应当：

·消除由最新备份的版本间碎片化所导致的恢复带宽减少

·向正在进行的备份引入不超过非常小(最好低于5％)的写入性能下降。

·不使去重的有效性劣化(必要时仅使用少量并且暂时的额外空间)。

·不需要很多的附加资源，诸如磁盘带宽、转轴和处理能力。

·在解决权衡时提供一系列选择。

<5.2想法>

在大多数情况下，在故障之后恢复最新的备份，因为用户通常对恢复最新的信息感兴趣(见图31)。基于该观察，我想以旧的备份为代价来消除最新的备份的碎片化(以便保持去重率)。在图47中给出了这样的方法的示例。图47呈现了在两种情况下作为版本号的函数的由跨备份版本的碎片化导致的恢复性能的下降。(1)具有随着备份存期而减少的碎片化的在线去重；和(2)离线去重，该离线去重引起将最新的备份连续写入磁盘和碎片化随着备份存期而增加。通过引入基于上下文的重写算法，我想将去碎片化能力添加至在线去重特征以便实现与离线去重类似的去碎片化效果，而没有相关联的成本。

如已经在第3.2章中呈现的，在具有在线去重的系统中，不再次写入已经存在的块，从而使备份过程非常快速。不幸的是，这样的方法可能导致高度碎片化，因为流中的两个相邻块可能最终在系统中彼此远离。为了防止这样的场景，CBR算法对来自传入备份流的块和其在系统中的物理局部化进行分析。为了最小化由版本间碎片化导致的性能下降，该算法会将重复块中的一些移动至新的物理位置以保持良好的流式存取并且使预取有效。因为在流的备份期间执行算法，所以不读取待移动的实际块(该读取成本可能很高)，而是写入在流中递送的副本。通过定期运行的删除过程来去除旧的副本。与离线去重相反，仅移动(重写)小百分比的块-确保最高恢复带宽增益的块。

尽管具有有限知识的缓存和CBR算法二者可以应对碎片化，但是他们呈现了完全不同的方法，并且针对不同种类的问题。前者不修改系统中的数据，并且通过使用可用的未来知识来在恢复期间允许有效的缓存内存使用。这样的方法允许缓存的重复块内部地存在于流中，从而导致内部流碎片化。在本章中呈现的后一种算法是完全不同的，并且不处置重新出现在流中的块。其主要目标是使所有的块在备份期间以更连续的方式结构化，并且应对所谓的版本间碎片化。然而，令人关注的事实是：这样的方法引起更有效的预取，该预取引起更准确被加载到缓存中的数据，其链接了两个解决方案。在我的实验中，单独地以及组合地对每个解决方案的的实际影响进行了进一步分析。

<5.3系统支持>

为了实现在下一章节中描述的碎片整理解决方案，备份存储应当支持以下特征：

·内容可寻址能力[66]：这是对下面描述的后续特征有用的基本特征。

·基于检查块散列存在的去重查询：至关重要的是，该查询是基于散列的，并且只需要读取元数据。针对呈现的碎片整理解决方案，是否试图对系统中的所有块或者所述块的子集尝试去重并不重要(诸如，利用稀疏索引[44])。然而，需要避免读取整个块数据以执行去重，因为这样的操作将导致读取碎片化的流的事实和非常低的总写入性能。而且，必须承认，对于高度碎片化，即使用于足够快地读取块元数据也可能没有足够的转轴。然而，存在基于闪速内存的用于该问题的解决方案[21、49]，而为了保持整个备份数据，SSD太小并且太昂贵。

·快速确定磁盘相邻块：给定两个块，系统应当能够快速确定它们在磁盘上是否彼此靠近。当确认在系统中的块存在的每个查询返回该块在磁盘上的位置时，可以实现这一点。

·能够写入已经存在于系统中的块并且去除旧的块。当决定再次存储块以便增加将来的读取性能时，需要该特征。这样的重写有效地使先前的副本无效，因为在恢复时将使用新的副本。

许多具有在线去重的系统——诸如DataDomain[83]和HYDRAstor[23]支持以上特征；对于其它系统，可以添加这样的特征或者其等效物。因此，可以将在下一章节中描述的算法视为通用的并且可广泛适用于具有在线去重的系统。

<5.4算法细节>

<5.4.1块上下文>

该算法利用复本的两个固定大小的上下文：其磁盘上下文和流上下文。将在流中的块的流上下文限定为紧接在该块之后的写入该流的一组块，而其磁盘上下文包含在磁盘上紧接该块之后的块(见图48)。当这两种上下文的交集很大时，对在该交集中的块的读取由于预取而非常快。实际上，通常都是这种情况，特别是对于初始备份而言。

当磁盘上下文包含来自流上下文的很少数据时，出现碎片化问题。这种情况的发生是由于在相同块在逻辑上存在于其中每个具有不同邻居的多个流位置中时进行去重。尽管这样的影响也是由内部重复块(内部流碎片化)所导致的，但是在先前的章节中提出的具有有限先期知识的缓存实际上消除了该影响。下面呈现的算法使我们仅处置在当前备份流中第一次出现的块。

注意，磁盘上下文大小与恢复算法严格相关，并且等于预取大小。另一方面，流上下文大小不能低于该值以便不限制最大交集。基于实验，磁盘和流上下文的通常大小默认设置为2MB和5MB。将在第5.5章节中对其它值的影响进行描述。

<5.4.2保持上下文类似>

基本想法是重写高度碎片化的复本，即，在当前备份中的其流上下文与其磁盘上下文显著不同的块。这样的重写的尝试是使两种上下文类似。在重写之后，块的新副本将被用于读取，这意味着还预取存储在相同备份中的其它块(因此减少碎片化)，并且最终在后台回收旧副本。

目标是仅重写一小部分块，因为每次重写会减慢备份并且消耗额外的空间，直到块的旧副本被回收。默认情况下，被称为重写限制的该参数设置为在当前备份中到目前为止所看到的块的5％。

算法在对正被写入的备份流以循环来迭代，决定每个遇到的复本是否应当被重写。待由算法来处理的当前重复块被称为判定块。

由于存储系统预先并不知道待写入的数据，所以在在线决定是否重写复本(无除了流上下文之外的未来知识)。考虑到以上情况，算法总是可以针对给定的复本做出次优选择：例如，通过决定重写复本，尽管针对在流中的稍后的另一复本，最好保留这样的重写“信用”；或者通过决定不重写复本，希望稍后在流中可以出现更好的候选；但是这样的候选实际上可能从未具体化。因此，对算法的挑战是作出良好的重写决定。

<5.4.3作出重写决定>

为了指导重写过程，我们需要引入复本的重写效用(rewrite utility)的观念。而且，将在每个循环迭代中维持并且调整两个阈值：最小重写效用阈值(常量)，和当前效用阈值(变量)。

重写效用

如果判定块的磁盘和流上下文的共同部分很小，则需要重写这样的块，因为这可以有助于避免一次额外的磁盘寻道以读取少量的有用数据。另一极端情况下，如果该共同部分较大，则这样的重写不会节省很多，因为读取大量有用数据所需要的时间分摊了额外的寻找时间。

因此，针对在备份流中的每个复本，将重写效用限定为在该复本的磁盘上下文中不属于其流上下文的块的大小，与该磁盘上下文的总大小有关。例如，70％的重写效用意味着在磁盘上下文中的块中的正好30％的数据还显现为在流上下文中的相同块。

最小重写效用

最小效用是CBR算法的恒定参数以便避免重写，这将仅稍微地提高恢复性能。我已经将最小重写效用设置为70％。该值可能看起来很高，但是如在下面的分析中呈现的，较低的最小效用不是很有用。

我们假设一种简单的情况：对具有5％的碎片化的重复块的备份，所有重复块都具有等于最小重写效用的重写效用。剩余的95％的块不是碎片化的(重写效用等于0％)。此外，假设对每个碎片化的块的预取不对除了满足该碎片化的块的重写效用所需要的块之外的任何有用数据进行预取。这样的场景以最大可能的努力来确保最小可能的增益。在这样的情况下，重写所有碎片化的复本潜在地将恢复性能提高大约12％(见图49)，在我看来，这足以证明重写的正当性。如果最小效用被设置为50％，则重写在类似备份中的所有碎片化的复本只会提供5％的改进，这似乎不够。

注意，可能存在这种备份：受到严重的碎片化影响，但是所有的复本具有仅低于最小效用的重写效用。然而，为了减少由这样的备份的碎片化导致的恢复带宽下降，算法将需要重写仅多于5％的块。例如，当所有的块具有70％的重写效用时，重写5％的块确保不超过2.15％的更好的性能。幸运的是，我并未在我的实验中遇到任何这样的情况。

当前效用阈值

当前效用阈值是限定当前判定块的重写效用的CBR算法的可变参数。为了计算其值，将最佳5％的块集合限定为，到目前为止在具有最高重写效用的备份流中所看到的所有复本的5％(默认值)。注意，每个可重写的块必须是复本，所以在一些情况下，可以保留少于5％的所有块，因为在流中可能没有足够的复本。

为了建立最佳5％，在不考虑算法采取的实际动作的情况下计算重写到目前为止所看到的每个复本的效用。在算法的每个循环中，当前重写效用阈值被设置为重写最佳5％块中最坏的块的效用。这样的选择大致意味着如果已经将该值用作从备份的开始直到当前点的每个判定块的当前效用阈值，并且没有对重写的块的数目的限制，则算法将重写所有的最佳5％块。

最初，将当前重写效用阈值设置为最小效用并且对于500个块保持在该水平以便允许对流中的第一个块进行碎片整理。因为该部分仅包含4MB的数据(通常来自许多GB)，所以此处未观察到5％的重写限制。

重写决定

在其重写效用不低于当前重写效用阈值的最大和最小效用时重写判定块。另外，不重写上下文交集中的所有块，即，将它们视为在当前流中的复本，并且通过算法的未来循环将其标记为跳过。注意，每个重写决定总是受到5％重写限制的约束，该重写限制是基于在到目前为止看到的流中的所有块来在线计算的。

决定是非对称的：仅重写判定块或者将交集中的所有块标记为复本。即，即使要重写判定块，也不存在重写(或者不重写)在交集中的其它块的决定，因为它们可能具有足够大的上下文交集以避免重写。然而，一旦作出将判定块保留为复本的判决，就应当将交集中的所有剩余块保留为复本，以确保对判定块的读取也将预取这些附加块(即，判定块的重写效用保持为低)。

块重写并不总是保证流和磁盘上下文的交集的大小将增加。例如，流上下文可以仅包含复本，并且算法可以决定仅重写它们中的一个，因为剩余的是连续的。在这样的情况下，交集的大小不增加。然而，重写的块最终仍然会在磁盘上靠近其它新的或者重写的块。当这样的块被预取时，它们很可能存在于读取缓存中，减少了恢复所需要的I/O数目，所以，重写仍然是有益的。

<5.4.4实现细节>

计算上下文交集

通过延迟该块写入的完成来填充判定块的流上下文，直到为该流提交了足够的写入请求。对于每个请求，通过基于数据的安全散列(即，SHA-1)发出修改过的去重查询(在磁盘上具有块位置的额外结果)来解决重复状态[25、24]。如果已经存在由算法的先前循环中的一个填充的查询结果，则不发出这样的查询。在检测到复本的情况下，修改过的查询返回在磁盘上的块的位置，并且返回块地址(散列)而没有进一步的延迟。在填充流上下文时，通过将在磁盘上的距离与判定块相比较来检查每个给定块，并且适格作为已经在磁盘上下文中出现的复本(或者未出现)。按照这样的方式，确定了磁盘上下文和流上下文的交集。

调整重写效用阈值

由于最佳5％的追踪效用是不切实际的，所以算法保留固定数目的效用桶(bucket)(例如，10000)。向每个桶指派不相交的相等子范围的重写效用，所有的桶覆盖整个效用范围，并且每个桶利用其在该桶范围中的效用来保持到目前为止看到的块的数目。这样的结构允许以最小的成本来以合理的精度达到近似最佳5％块中的最坏块的重写效用-在指派给每个桶的效用范围内。实际上，只有表示高于最小重写效用的值的桶是有用的，但是在这两种情况下，这样的结构所需要的内存是可忽略的。

对内部流复本进行过滤

我的实验显示，实际上每个备份流都包含是来自流的一些其它块的复本的块(内部流复本)。由于未降低去重率，因此不存在用于确定这样的内部复本的最佳位置的在线方式，可以将在来自流的对应重复块的邻域中的任何磁盘位置视为潜在的好位置。然而，重要的是，出于重写之目的，在流的每个版本的备份期间，通过CBR算法来选择相同的逻辑位置，并且其它位置不触发这样的操作。这是必需的，以便在每个备份期间不将内部重复块从逻辑流中的一个位置重写到另一位置(抖动(thrashing))。另一方面，具有在先前的章节中描述的先期知识的缓存表明应当将在逻辑流中的第一位置视为是具有最高可能性的位置。一旦被读入缓存，其就能够有可能长时间保持在那里服务对相同数据的其它请求。因此，只有在块首次出现在流中时才应考虑重写。

因为有关作为内部复本的知识不需要是精确的，并且能够已知利用一些近似来在写入每个备份的大小之前知道该每个备份的大小，所以，我们可以使用布隆过滤器[9]来使用相对少的内存。在判断适格用于流上下文之前，应当在过滤器中验证每个块的存在。如果找到块，则应当通过标准机制来将该块写入系统(可以是误报)。另外，应当设置指示块存在的滤波器中的适当位数，并且该块应当适格用于流上下文和用于CBR算法。注意，当备份完成时，不再将位设置为零，并且删除整个布隆过滤器。

在这样的情况下，针对每个1GB的预期数据，我们需要大约240KB的内存以便不超过流的最后字节的0.1％误报率(每密钥15位、128×1024个密钥、7个散列函数)。这样的数目是可接受的，因为正如具有最多5％的块要重写，通常它们中的少于4个(粗略估计)将被错误地假设为内部复本。因为1GB的数据需要至少500次I/O，所以对恢复带宽的负面影响将通常远小于1％。

通常，散列的过程确实需要附加的处理能力，但是这种情况不同。由于在所考虑的系统中，我们已经计算了整个块的散列(160位或256位)，所以我们可以仅使用该散列的一些所选择的位来作为布隆过滤器的良好散列函数。这样的优化使对附加处理器周期的最终需求可忽略。

在写入期间读取模拟

所呈现的CBR算法在通过重写小数目的块来确保更多的连续磁盘存取时表现良好。然而，最后，重要的是在读取流时实现的恢复性能。将该结果保持在相同水平，连同进一步减少重写的块的数目一起，将有助于降低在每个备份期间的所支付的成本。

为了实现这一点，在备份期间利用标准的LRU缓存逐出策略来执行恢复模拟。代替块散列，将块位置识别符保留在内存中。由于我们可以模拟对尚未存储到系统中的块的读取。结构需要LRU队列和映射来检查传入的块位置是否已经在缓存中，该块位置应当占用不超过384KB的内存，其中模拟128MB的缓存(3x8字节x128MB/8KB)，针对在大多数数据集中的所有缓存大小，该模拟得出非常类似的结果。在引入该增强之后，重写的块的数目变得低于大约20％至30％，同时保持类似的恢复带宽。

在备份期间模拟利用先期知识而不是LRU的缓存的算法将很可能在减少重写的块的数目中带来更好的结果，但是更复杂(需要附加内存和延迟)，并且将被考虑用于未来的工作。

后台操作

CBR算法需要去除重写的块的旧副本的后台过程。有时，该过程可以连同已经不时地运行的其它维护任务一起完成，诸如删除、数据清理和数据排序[23]。在执行该去除之前，重写所使用的附加空间暂时减少去重率。因为这样的数据的百分比有限，并且维护任务通常执行得相当频繁，所以这样的解决方案应当是容易接受的。

对读取操作的修改

如果数据块是内容可寻址的，则旧的和新的副本二者都具有相同的地址，因此当用新的副本替换旧的副本时，不必改变指向数据块的指针。如果系统先前不允许相同块的许多副本，则为了确保最新备份恢复的良好性能，只有存取块的最新副本的程序可能需要稍微修改。可以通过仅保留在块索引中的最新块的条目来完成该修改。

<5.4.5内存需求>

如在第5.4.4章节中描述的，算法中潜在需要大量内存的部分是用于消除内部重复块的布隆过滤器。所需要的内存大约为每GB备份流大约240KB，这看起来不大，但是较大的流对该需求更严格。

由于在流备份期间使用的通常的内存量处于数十GB的水平，所以所提出的解决方案对于高达100GB(24MB的内存)或者甚至1TB(240MB的内存)(取决于可用的系统和确切内存)的流大小是可接受的。注意，根据Wallace等人从超过10000个备份系统收集到的数据[79]，大于500GB的流平均使用备份系统中的不到5％的总容量，这使它们通常非常罕见。

必要时，总是可能基于其逻辑内容来将一个大型的流划分成较小的流，从而确保更多的共同数据被放在一起(见第3.2.3章节)。替选解决方案还使用不那么精确(较高数目的误报)或者经压缩的布隆过滤器，其代价是经过碎片整理的块的数目较少或者对其数据的存取更复杂。

最后，上述的布隆过滤器和默认大小为5MB的流上下文是被存储到系统中的每个流所需要的结构。这意味着，最终的内存量应当乘以预期的流的数目。

<5.4.6讨论>

优化在线算法

CBR算法显然是在线的，因为它仅关注目前为止看到的块(加上可以被认为是先期知识的小型流上下文)。不幸的是，由于相同的原因，其仅在当前效用在整个流中是稳定的情况下是最佳的。在其它情况下，特别是具有在流的开始与结束处的块的重写效用之间的大变化，连同充分利用5％重写限制一起，最终结果可能不是那么好(尽管仍然比碎片化之前更好)。

通过为整个流设置固定的重写效用，可以优化地解决所有恶意场景。这样的效用的最佳值将是通过当前效用算法计算并且在流的末尾处实现的值。不幸的是，这样的信息将需要在存储该流之前进行将来的分析。可以进行简单的近似以使用在相同数据集的先前版本的备份期间收集到的统计资料。

幸运的是，在所有经测试的数据集中，以上问题处于最低级别还因为所重写的块的数目总是低于5％的水平。因此，即使利用在线算法，最终结果也非常接近于利用无版本间碎片化所实现的最终结果。

离线CBR

可以引入CBR算法的简单修改，其似乎消除了其成本并且保留了优点：首先，识别待重写的块，并且在备份完成之后，稍后在后台将它们重新写入。然而，这不能很好地运作，因为重写将需要读取碎片化的块，这可能极其慢(正是因为它们是最碎片化的)。在CBR的在线版本中，当用户正在写入数据时，这些块实际上几乎是免费接收的。

<5.5权衡>

流上下文大小

算法默认使用5MB作为流上下文大小，因为其足够大以允许CBR有效并且足够小从而由于填充该上下文而导致的写入延迟的增加是可接受的。假设备份系统对于单个流实现100MB/s[83]，则将最多花费50ms来填充上下文。还验证2MB与20MB之间的其它值，并且该其它值是可接受的以仅利用稍微不同的最终带宽结果来降低或者增加期望的时延，但是重写的复本数目存在较大变化(较大的流上下文意味着较少的待重写块，但是恢复带宽更低)。另一方面，当延迟在一些系统中至关重要时，有可能通过我们能够等待写入确认的最长可接受延迟来限定流上下文的大小。在这样的情况下，每个块的流上下文将不同，但是其仍然应当提供合理的去碎片化结果。

注意，将仅针对已经具有显著时延的非重复块引入来自以上示例的延迟。

重写数目

即使将重写数目的默认限制设置为在流中到目前为止出现的所有块中的5％，但是在一些单独需求的情况下，可以轻易地修改该值。具有较高限制将使具有高于最小重写效用的重写效用的所有块被重写，并且可能对于被备份了长时间而没有进行CBR去碎片化的流非常有用。当然，这样的备份的时间将成比例地增加，但是从下一备份开始，限制可以回复到5％。

而且，在仅可接受最小带宽下降(例如，低于1％)的情况下，降低限制可能是有用的。在这样的情况下，算法将在选择待重写的最碎片化的块时起到很好的作用，从而利用最小的相关联成本来提供最高增益。

<第6章对踪迹驱动模拟进行评估>

<6.1实验方法>

我的实验的目标是：在没有任何瓶颈而只有磁盘本身并且不探究每个特定实施方式的细节的情况下示出所有或者至少大多数系统所共有的环境中的问题。如此，我优先考虑的是：在没有利用架构假设来模糊实验的情况下评估实际碎片化问题的严重性和其解决方案的效率，这通常只是一些给定实施方式的限制。换言之，可以将在本章节中呈现的结果视为性能的上界，对于具有在线去重的最普及的系统尤其重要。注意，即使具有离线去重的系统不受版本间碎片化影响，它们也仍然必须处置内部地存在于流中的一个版本间碎片化。为此，在第4章中呈现的并且在此处进行了评估的利用先期知识的缓存非常有效。

在我的同事的额外帮助下，我准备了能够在数千种可能的配置中执行并行测试(在许多内核和机器上)的12000行C++模拟器。已经从真实用户收集到的实际踪迹之后，模拟器产生结果和统计数据，其引出结论和最终呈现在本文中的数字。尽管这只是所获得的结果中的一小部分，但是呈现的数字是对分析和克服存在于具有去重的备份系统中的碎片化问题具有最大影响的数字。

<6.1.1备份系统模型>

我提出一种备份系统模型，该模型足够一般以表示具有在线去重的绝大多数备份系统的共同部分，足够简单以特别针对主要问题特性来实现，并且足够高效以在有限时间内执行大量实验。

写入模拟

在模型中，我已经假设了一种简单的存储子系统，该子系统由一个连续空间(作为单个大磁盘)组成，该连续空间在每次测量开始时是空的。将模拟器中的写入过程设计为保留存在于具有在章节3.2中描述的在线重复消除的系统中的所有特征，其中主要特征诸如局部性维持块布置(locality preserving blocks placement)[83]和在当前被占据的区域之后放置新的块。这样的写入算法确保最大写入带宽和最小的资源利用，这些在执行备份时始终是优先的。

被用于模拟的数据是从真实用户收集到的。为了优化该过程，通过使用Rabin指纹识别[67、12]来将给定数据集的每个版本分块成平均大小为8KB的块(作为当今备份系统中最普及的块)。在这样的过程之后，存储仅具有短散列(64位)的踪迹和每个块的大小并且将其用于所有的模拟。由于没有必要在每次执行实验时执行组块和散列，并且有可能将整个磁盘镜像保持在系统内存中，这使测试过程非常有效率。

恢复模拟

如在章节3.1.2中描述的，通过使用预取和缓存来进行读取在存储环境中最常使用。

在所有实验中，使用固定大小的预取，所以，我们可以假设在恢复期间，读取带宽与数据I/O操作的数目成反比。虽然确实存在性能受其它因素影响的系统，但是我认为将实现的带宽与固定大小的I/O的数目相关使我们能够专注于碎片化问题的核心，并且忽略次要因素，诸如网络和CPU速度。

我假设2MB的恒定预取大小作为当今磁盘驱动器所具有的最有效率，即使具有最碎片化的数据(见下一章节的证明)。缓存大小在被恢复的每单个流128MB至高达1GB之间变化以更好地将问题可视化，而具有无限大小的缓存的实验提供有关最大理论限制的重要信息。使用通用LRU数据替换策略作为最普及的策略[53、48、41]以便示出当前性能水平。

注意，在利用先期知识的实验中，仅将具有已知的未来出现的块保持在高速缓存中。如果先期知识较短或者仅存在很少数目的在将来使用的块，则可能未充分利用缓存内存。这样的方法不是最佳的，但是我决定使用它以清楚地将这些限制可视化。而且，我的实验显示，按照与LRU类似的方式来保持内存充分利用仅有极少帮助或者根本没有帮助，特别是在具有较大的先期知识时。基于该结果，清楚的是，应当首先使用任何附加内存来扩展先期知识，这表明在谈及特定实施方式时，在智囊与缓存之间存在动态内存划分。

对磁盘上下文/预取大小的选择

针对按顺序放置在磁盘上的数据，预取非常有效。为了在具有去重的环境中显示这一点，我已经对所有的六个数据集都执行了具有从512KB到8MB的经修改的固定预取大小的模拟(见图50)。由于此处的比较是通过使用不同的预取大小来完成的，因此，无法再进行仅基于I/O数目的性能外推(在这样的情况下的比较结果取决于磁盘在寻道时间内可以读取到多少数据)。因此，我已经使用了共同的企业数据中心容量HDD规范[71]来说明有关所实现的性能的原因。

正如我们可以在图表上看到的，在碎片化的和没有碎片化的数据的6种情况中的4种中，利用预取大小等于2MB实现了最短的恢复时间。唯一的例外是Wiki和通用文件服务器，对于它们而言，8MB的预取稍微更好。基于这些结果，我已经决定针对大多数测试使用2MB的预取，以作为对于具有共同的LRU缓存的碎片化的和没有碎片化的数据两者最具代表性的预取。当使用利用先期知识的缓存的较大预取大小时并且在考虑到可扩缩性视角之后，在单独的章节中清楚地标记了这两个例外并且显示了进一步恢复带宽增加的可能性。

虽然可变预取大小还可以是一个选择，但是其只能在一定程度上掩盖碎片化，特别是在关注流存取时。通过在检测到随机读取时读取较小量的数据，可以提高当前性能，但是如果检测到流存取不够快，也可能降低当前性能。而且，每次根据最大值来修改预取时，最大可能的性能也会受影响。此外，这样的解决方案需要有关系统及其结构的许多假设。因此，我决定在我的实验中使用固定的预取大小以基于在测试中执行的I/O数目来外推带宽。

该测量忽略了由于文件系统物理碎片化而导致的一些速度变化，当特定I/O彼此接近时进行更快地寻找，并且当特定I/O彼此远离时稍慢地进行寻找，这有利于显性成本：单个I/O读取时间。

<6.1.2忽略的因素>

在我的实验中，我忽略了增量备份(在具有重复消除的系统中，它们实际上与完全备份非常类似，因为仅存储新的数据)，许多用户通常每天都执行该增量备份。不幸的是，在我的实验中，好心同意使用增量备份的数据的用户并不具有增量备份。尽管利用这样的数据的实验将是有价值的，但是该实验将只扩展我的实验已经呈现出的情况。可以肯定的是，这样的备份无法消除也无法减少碎片化问题，因为在整个星期之后，它们最终在相同的存储区域写入类似的新数据。实际上，因为日复一日的修改较小并且较频繁，所以随着来自一周的新数据现在被划分为5至7个区域而不是一个区域，它们甚至可能使问题更严重。

在现代备份系统中，能够立即处置许多备份是关键特征中的一个。即使在我的实验中，仅验证了单个流负载，但是这样的方法允许我提供一种可重复的方式来执行实验并且利用在磁盘上的最佳块布置来显示结果(没有来自其它集合的数据和限制预取能力的容器)。一次写入许多流导致与实施方式有关的许多问题，这将需要从每个系统的角度来单独探究问题。因为这不是我的目标，所以我决定提供最简单的实施方式，从写和恢复带宽二者的角度来看，该实施方式实际上应当接近每个系统的最佳情况。同时正写入的每个附加流需要至少解决将所有流存储在单独的容器中的问题，这潜在地引入了额外的碎片化。

在数据保留以及因此数据的删除的方面总是与备份系统一起存在，并且在考虑到去重时尤其困难。因为将单个备份系统存储了相当长的时间，所以在某一时刻，需要作出去除哪些备份的决定。这还影响数据碎片化。实际上，实验显示，除了改变整体去重因子[48]之外，针对删除备份的确切时程不会特别以另一种方式来影响结果。而且，在我的实验的情况下，在每个数据集中的备份的数目相对较少，因此，对其应用数据保留策略并且验证碎片化变化将使我无法得出足够一般的结论。

在我的实验中忽略的因素中的一个是全局去重(在整个系统内)，该全局去重可以在市场上的系统中的一些中找到[23]。其主要原因在于，连同有限的影响因子一起难以执行测试并且给出可靠的结果。在第3.2.3章节中呈现了我的决定的细节。

<6.1.3数据集描述>

为了诊断碎片化问题并且验证提出的算法，我已经收集了表示超过5.7TB大小的真实用户数据并且由6个每周的完全备份的集合组成的踪迹。在图51中对每个集合的特性进行了描述，而在下面呈现了其内容的类型。

·开发项目-大型C++项目cvs数据、LDAP数据、服务器配置文件

·问题库-问题库数据(包含XML和附件)、服务器配置文件

·Wiki-维基数据、服务器配置文件

·通用文件服务器-计算机科学研究实验室的主目录(网件)

用户目录-在一个软件公司(tar)中的18个用户的linux主目录

·邮件-在软件公司(tar)中的35个用户的邮箱

<6.1.4测试场景>

每个测试总是从空系统开始，并且除此之外，可以在三个不同的场景中执行参数(诸如，缓存和预取大小、缓存算法、先期知识大小)：

·基础(base)-来自一个接一个加载的数据集的所有备份(包括内部和版本间碎片化)。

·碎片整理(defrag)-来自一个接一个加载的数据集的所有备份，其中，启用CBR去碎片化(内部和版本间碎片化二者，其中由CBR算法来限制最后一个备份)。注意，该结果将仅在实际使用CBR算法的实验中示出。

·最大(max)-只有来自加载到系统中的集合中的最后一个备份(只有内部流碎片化)。可以将该结果称为流的潜在最大带宽水平[当使用无限制的缓存大小时，其实际上是最大的]。只有利用离线去重其才能被认为是现实的，但是只能连同相关联的成本(见第2.2.1章节)。

每个场景的目标是使处于碎片化的(基础)、去碎片化(碎片整理)和未碎片化的(最大)状态的系统可视化以便测量所呈现的算法的有效性，并且将不同选择与无去重版本以及在彼此之间进行较(在所有实验中的x轴)。注意，无论场景如何，内部流碎片化总是存在于流中，因为它无法在不降低去重水平并且不改变逻辑结构的情况下被消除。而且，如已经在第3.2.1章节中陈述的，其会对最终结果产生很大的影响，使在所有场景中的数目有时与利用无重复所实现的水平相距甚远(以消极和积极两种方式)。

另一重要的观察是，可以将连同无限的缓存大小的max场景视为理论上可实现的最大带宽(因为整个备份被按照读取的顺序放置在一个连续区域中，并且一旦所有块被读取，将永远不会从缓存中逐出)。

<6.2对先期知识缓存的评估>

<6.2.1满足需求>

性能结果

在第4章中呈现的具有有限的先期知识的缓存在碎片化的和未碎片化的数据(包括离线去重)二者的每个备份(包括最新备份)的恢复期间优化内存使用时确实进行得很好，从而确保了平均恢复带宽增加了62％到88％之间(见图52)。

此外，六分之四的仅具有256MB的缓存内存以及8GB的先期知识的没有碎片化的数据集合已经提供了与利用无限的缓存大小所实现的结果几乎完全相同的结果。对于其它两个(用户目录和邮件)可能的选择是要么保持256MB大小的缓存并且获得22％至73％的附加带宽——即使在与具有1GB缓存的LRU相比较时，要么使用相同大小的1GB缓存以具有22％至253％的带宽提升和可能额外20％更大的前期知识。在图53和图54中示出了精确的结果，而其详细分析可以在以下章节中找到。

除了以上特性之外，利用先期知识的缓存支持基于可用资源和恢复带宽需求的一系列选择。有可能在低8倍的内存使用并且依然略微更好的性能(1GB的LRU相对利用先期知识的128MB)的较便宜的选择与具有相同内存量但性能更高的选择之间进行选择(见图52)。取决于实际的系统使用模式，两个选择听起来都非常令人关注，同时具有来自当前最普及的LRU算法作为缓存替换策略的重大飞跃。

附加资源使用和可能的权衡

如在第4.4.4章节中详细描述的，对有限的先期知识的使用需要附加资源，该附加资源应当被包括在总成本中。在最有效的情况下，它们是：内存(大约13MB用于8GB先期知识)和带宽(大约0.256％的降低)。虽然后者足够小而变得可忽略，但是前者可以产生一些差异，特别是当缓存内存的总量较小时。尽管假设256MB的缓存通常是最有效的，但是具有8GB的先期知识仅导致大约5％的更高内存使用。该成本似乎不高，假设带宽增加和其有多接近无限的先期知识。

注意，在我的实验中，该附加内存默认没有被包括在总缓存大小中。这使得能够在保持完全相同的缓存大小的同时清楚并且容易地将不同的先期知识大小和其对性能的影响进行比较。而且，可能的实施方式中的每一个需要不同的内存量，这使该情况可视化变复杂并且将需要更多的测试。

可调谐性

还可通过以附加内存为代价来设置所请求的先期知识的大小来调谐利用先期知识的缓存。一般而言，先期知识越高，解决方案越好，但是具体的，该属性是有限的并且依赖于内部重复模式、缓存内存的大小和流的状态(碎片化的或者没有碎片化的)。如已经在第4.5章节中提到的，期望的解决方案将是：在实际缓存与在可用的一些总内存量内的先期知识之间自动化内存划分以便确保最佳性能结果。

代码修改和去重

虽然在一些给定的实施方式中，需要代码修改来使用算法，但是其非常有限并且不影响去重有效性。必要的两个修改通常仅考虑负责数据恢复的算法和使用已经可用的接口的缓存内存管理。前者只是为了向智囊填充实际的先期知识而请求，并且可以通过向每个标准的读取请求附加适当的信息来轻易地完成，使得对其它系统部件上的修改几乎不明显。另一方面，后者仅限于恢复算法，仅使简单地交换实施方式变得容易。这样的有限的修改使算法合适于市场上存在的大多数(或者可能甚至全部)系统。

<6.2.2设置先期知识大小>

图53和图54示出了利用先期知识的缓存的影响——受限(限制到512MB、2GB、8GB)和不受限(与在本文中之前使用的所采用的B'el'ady的缓存相同))，连同与标准的LRU算法的比较一起。

在这两个图中，当实际使用任何数目的先期知识时，我们可以注意到非常好的结果，然而利用最小的缓存大小，最高增益(当与LRU相比较时，以百分比为单位)几乎总是可能的。这是因为少量的缓存使得LRU算法高度无效，因为在再次请求块之前，块已经被从缓存中逐出(尤其体现在开发项目和通用文件服务器数据集中)。利用先期知识，在缓存中的每个块具有其自己的目的，并且在至少使用一次之前不被逐出(除了一些罕见例外——当要比已经存在于缓存中的一些其它块更早读取预取的块时)。而且，较小的内存量使得在几乎所有情况下和整个实验中缓存被100％地利用，这对于较高的值而言并不总是对的(详见第6.1.1节)。例如，未碎片化的开发项目实现已经最大的带宽，其中缓存内存仅为128MB，即使在具有无限的先期知识时也是如此。

增加先期知识总是有助于改善所实现的结果。然而，增益与已使用的缓存量和存在于流中的内部重复块的模式高度相关。复本的问题限定了不从磁盘重新读取块的必要的内存的最小大小，该最小大小实际上是缓存的期望大小。在有限的先期知识中能够找出所有的块以保持在内存中并且具有所需要的内存大小使得该过程最有效。特别是在邮件数据集的情况下可以注意到该特性，该邮件数据集包含最大量的内部复本。在这两个图上(碎片化的和未碎片化的)，相较于具有较小的内存和先期知识大小，具有1GB缓存和8GB先期知识得出好得多的结果。

另一方面，存在许多情况，其中有限的先期知识实际上限制了缓存内存的使用。在我的实施方式中，每当模拟了利用先期知识的缓存时，仅在内存中保留将来要使用的块(在先期知识中找到)。因此，应当将在这种情况下的缓存量视为最高限制而不是使用中的特定内存量。实际值可以在整个模拟中变化，但是在某一时刻，其达到它的峰值，这意味着添加额外的内存不会改善结果(除非使用更多的先期知识)。这样的场景最容易在被限制为512MB的先期知识中看到。在这种情况下，多于128MB的缓存将不会为呈现的数据集中的任何一个带来任何明显的益处，因为将实际使用不超过128MB的缓存。根据对于未来知识的其它限制，这样的边界对于每个数据集是不同的，并且能够容易地从图53和图54读取到。

为了了解整个局面，受关注的是考虑与整个备份的大小有关的先期知识。正如我们可以注意到的，当比较图53与图54时，一个在全局上准确的断言似乎是碎片化的数据需要比未碎片化的数据更少的先期知识(详见下一章节)，这得出结论：用于先期知识的内存应当随着数据集的寿命而改变。其它洞察取决于流的详细特性，而不是流的大小。当我们查看图表时，对于具有128GB缓存的所有数据集来说，具有2GB的先期知识完全足够，而对于256MB——特别是对于问题库而言有点少，该2GB的先期知识实际上非常少。当具有非常大的流时，可以改变的是到使用无限的内存的最佳算法的距离，这是可以理解的。对于用户目录的情况尤其如此。

<6.2.3碎片化对所需要的缓存大小的影响>

当针对具有不同的先期知识大小的缓存内存使用效率再次比较图53与图54时，可以观察到一个受关注的事实。虽然针对前者(具有版本间碎片化)，8GB的先期知识即使对于1GB缓存来说都足以保持在具有无限的先期知识的算法的最大8％内(平均2.48％)，但是由于随着每个I/O恢复更多值得保留的数据，因此未碎片化的选项具有更高的需求。在这种情况下，8GB的先期知识非常适合高达256MB的缓存(离无限制选项的偏差最大为2.3％；平均为0.83％)，其中，在具有512MB时已经示出不足(最大为19.25％，平均为5.48％)。对于该缓存选项和更大的缓存选项，需要更长的先期知识。注意，在我的实验中，仅将在先期知识中发现的块能够被保留在缓存中(详见第6.1.1章节)。如果先期知识较短或者只存在小数目的要在未来使用的块，则可能没有充分地利用缓存内存，当具有不同内存大小的两个结果相同时，通常可以在图上注意到该点。

为了测量每个数据集的最大内存需求，我已经利用无限制的内存量和无限的先期知识执行了测试。图55中的结果显示，即使在利用先期知识的情况下，数据碎片化也对所需要的内存具有很大的影响。在6个情况中的3个情况中，内存需求在允许版本间碎片化后翻倍，而针对问题库，该内存需求乘以9倍。剩余的两个数据集的需求保持在非常类似的级别。

<6.2.4利用更大预取进行试验>

由于第6.1.1节的观察，我的试验中的大多数是利用2MB的固定默认预取大小来执行的，因为该大小对于最普通的LRU算法观点最有效并且提供了在不同算法之间的容易的比较。这样的水平的预取大小(2-4MB)也与在许多论文[48、53]中使用的预取大小相似，表明可以将其视为最常见的预取大小。虽然如此，但是其表明了使用利用先期知识的缓存算法显著修改了这些假设。为了将针对预取大小在恢复带宽方面的差异可视化，我已经利用普通企业磁盘特性执行了模拟[71](保持数据传输速率为175MB/s，读取存取时间为12.67ms)。在图56中示出的结果表明：在每个条件下(碎片化的和未碎片化的)，并且通过使用不同的恢复算法，每个备份具有自己的最佳预取大小，该最佳预取大小对于彼此可以大不相同。一个清楚的观察是：当与碎片化的数据相比较时，这样的最佳预取针对没有碎片化的数据始终更大，并且当与LRU相比时，该最佳预取对于先期知识算法始终更大。因此，转换到更大的预取通过更小数目的I/O改善了恢复带宽，该更小数目的I/O限制了非生产性的寻道。由于使用了先期知识算法，预取大小可以比利用LRU的情况大2到6倍，因此，针对碎片化的数据，提供了水平为11％-117％(平均为68.47％)的最大恢复带宽增加，并且对于未碎片化的数据，提供了水平为27％-252％(平均为120.24％)的最大恢复带宽增加。当与利用先期知识和2MB的预取实现的结果相比时，扩展预取大小对于碎片化的数据可以产生0％-48％(平均为23.89％)的附加增益，并且对于未碎片化的数据可以产生3％-92％(平均为53.90％)的附加增益。

<6.3CBR有效性的评估>

<6.3.1满足要求>

性能要求

在第5章中提出的CBR算法在消除版本间碎片化对所有踪迹的影响时非常有效。在具有256MB的LRU缓存的普通场景中，得到的在每个数据中的最新备份的恢复带宽平均在最高带宽的2.48％内(从21.29％内)，这是利用无版本间去重来实现的(例如，通过存储单个备份)。尽管这指示了平均仅为29.1％(8％-94％)的恢复带宽增加，但是重要的事实是应当纳入考虑的进一步劣化角度。不幸的是，由于缺乏涵盖多年的备份的踪迹，此处无法示出该算法的真实潜能(细节请见第3.3.2节)。

当更深入地探究图57中示出的结果时，可以特定于每个数据集来进行一些受关注的观察。例如，对于问题库的备份2和7，发生了碎片化的最大增加。这最可能是由数据删除所导致的，因为这些备份是显著小于它们的前身的仅有备份。另一方面，在用户目录和邮件图上可见的峰值是由未完全完成的备份导致的，而其它峰值通常在备份流特性方面与集合中的通常备份大不相同。不幸的是，我无法验证这些偏差的核心原因。

使用的额外的空间和资源

除了重写的重复块之外，我的算法没有使用额外的空间，因此，额外的空间消耗低于所有块中的5％。实际数字低得多，介于0.35％与3.27之间(平均为1.58％)。在后台去除块的旧副本，例如作为周期性运行的删除过程的一部分，所以空间消耗仅仅是临时的。另外的磁盘带宽消耗也仅限于对重写的块的写入。

可调谐性

通过设置待重写的块的百分比，也可容易地调谐所提出的算法。百分比越高，恢复性能越好，代价是写入性能下降越大，临时存储重写的块的旧副本需要的磁盘空间越大。

<6.3.2重写的成本>

当对所提出的算法的成本进行评估时，我已经估计到了由重写导致的备份过程的减速。由于CBR将复本重写为非复本，所以，为了建立这样的操作成本，我已经修改了商用备份系统HYDRAstor[23、55]的写入路径以避免校核复本，并且将得到的带宽与未修改的系统在写入100％的复本时的带宽进行比较。

结果，复本的带宽比非复本高3倍。基于该数字，我已经使用了减速因子4来重写块(针对标准复本写入/验证使用1，针对额外写入使用3)，对比对该块进行去重。例如，重写5％的块导致从5.17％上至15％的减速。由于所有重写的块都是复本，所以实际减速取决于复本在原始流中的百分比——百分比越高减速越高，并且，当流中的所有块都是复本时，实现了15％的减速。

所提出的最大减速似乎很显著，但是，如实验所示出的，该算法几乎从未达到过最大允许的重写(见图58)。这是因为我非常保守，由于将最低重写效用设置为高(70％)，并且我在处理备份流的同时始终遵守5％的限制。因此，CBR将备份时间增加了1％-9％(平均为4.21％；见图58)，这看起来是合理的。然而，仍然存在将重写的块的限制设置得更小的可能性，以便降低潜在的成本并且仅用最大的增益来执行重写。

减少由重写本引入的成本的替选选择是仅每n个备份便执行该算法。这样的解决方案也应当很有效，并且，以一些恢复带宽为代价，在备份过程期间引入更小的开销。

注意，该权衡还解决了在后台执行离线去重所需的资源和在备份之后需要的临时空间的量，因为它们与重写的块的数目成正比。

<6.3.3设置重写限制>

为了为重写限制选择最佳值，我执行了实验：使该限制在0％至8％之间变化，同时保持最低重写效用为70％不变。在图59中给出了在每个备份集中的最新备份的结果。对于除了问题库之外的所有集合，将该限制设置为低值——诸如2％甚或1％)都非常有效，对于问题库，5％的重写限制使恢复带宽的下降最低。将该限制增加到超过5％不会产生额外的改善，并且可能会显著增加备份时间，所以我决定针对所有实验都将该限制设置为5％。尽管利用该设置，最大理论写入带宽下降也在15％的水平，实际上，最大理论写入带宽平均仅略高于4％。同样，仅对于100％重复的流才能实现最大下降，在这种情况下带宽已经非常高。

注意，对于大多数数据集，重写的块的数目与获得的恢复带宽成正比。在邮件的情况——其中内部碎片化非常严重——下，该相关性极弱，并且在Wiki数据集的情况下没有相关性。后者是由刚好在最后一个备份之前的很不寻常的备份导致的，与该集合的标准备份相比，添加了大约15倍更多的块并且删除了更多的块。该算法正试图对产生许多重写本的备份进行去碎片化，而下一个备份(在集合中的最后一个备份)与其它备份非常相似，这使该算法基本上再次重写了来自上一个备份的大多数块。

令人关注的事实还有：在去碎片化之后的用户目录恢复带宽实际上比不具有碎片化的版本(被存储为系统中的单个且唯一的流)更好。这是由于块重排序，块重排序幸运地使缓存更加有效。该观察还示出，存在按照与用户所请求的顺序略微不同的顺序来写入备份的可能性，但是，如我的一些其它测试所建议的，这样的效果仅对于LRU算法有可能，因为其通常并不非常有效(其可能会要求有关被写入的整个流的先期知识并且会在运行期间或者在昂贵的后台操作期间对块进行重新布置)。当缓存配备有先期知识时，这样的现象不会发生。

经重写的重写本

我的实验示出，最新备份中的所有重写的块的甚至39％至97％都是已经重写到其中一个先前备份中的块。在新块的数目非常低的备份中，该数目达到最高，从而为了最终实现足够大小的上下文需要多次迭代。即使再次对这些块进行重写，也并不意味着这些块是不必要的(实验使得不可能具有已经重写在先前备份或者最终恢复性能下降10-20％的任何备份中的重写本)。在一些情况下，重写只能很少地有助于减少重写效用，尚未达到低于所要求的水平，或者仅仅是将块移到周围，这增加了在需要之前进行读取的可能性，但是不会明显影响其重写效用值(由于恢复缓存)。，利用以这样的方式修改的算法的结果来很好地可视化这两个方面，该方式为了重写块，在其流上下文中应当找到至少一个非重复的块(以便确保下一次会降低其重写效用)。这样的实验显著地减少了(甚至减少了一半)重写的块的数目，但是其也将实现的恢复带宽降低了几个百分比。利用将流上下文增加到甚至100MB，可以实现类似的结果。

由于重写的块的总数目仍然非常小，我已经决定保持该算法的该版本从而确保更好的恢复带宽。

<6.3.4压缩的效果>

至此，我们已经假设备份数据是不可压缩的。如果我们保持预取大小恒定并且等于2MB，则在碎片化中的可压缩数据结果增加，并且CBR算法在恢复带宽方面带来甚至更好的相对改进。例如，对于50％可压缩的数据，对于受测数据集的恢复性能下降从12％-51％(平均为21.27％)增加到16％-56％(平均为26.12％)，而CBR去碎片化将最新备份的恢复提高了11-121％(平均为35.79％)而非8％-95％(平均为28.94％)，致使总下降降低了高达10％(而不是在未进行压缩情况下的高达7％)。所有的结果都是利用非常相似数目的重写的块来实现的。

显然，例如基于数据的可压缩性来选择不同的预取大小可以改变以上结果。

<6.3.5CBR去碎片化过程对所需缓存大小的影响>

为了从所需的缓存内存方面验证CBR去碎片化的过程，我已经执行了如下测试：在利用无限先期知识和潜在无限制缓存大小进行去碎片化之后读取每个数据集的最后一个备份。在图60中可以找到在每种情况下的实际峰值内存使用率。收集到的数字表明，CBR去碎片化过程在限制内存使用率并且因此使最新备份与在内存使用区域中从未碎片化的备份相似方面非常有效。

<6.4这两种算法的组合影响>

图61示出了在针对具有不同缓存大小的最新备份的单个选择和组合选择中利用有限先期知识缓存算法进行CBR碎片整理的详细结果。作为示例，这两种算法被用于应对碎片化的不同方面，最终产生了非常有效的共生(symbiosis)，对于256MB的不同数据集使得带宽增加了16-388％(平均为142.65％，见图62)。

而且，在与利用仅具有256MB的缓存内存(见图64)的无限制缓存大小所实现的最大可能恢复带宽相比，该算法产生了非常好的结果。在总共6种情况中，有4种情况的结果与理论最大值仅相差至多13％，留下的改进的空间不太大，而剩余的2种情况仍然落在后面。用户目录(-34.15％)是极大的数据集并且需要更大的缓存和更高的先期知识二者以便带来更好的结果，而邮件(-71.15％)包括内部复本块中的大部分，这些块需要更多的内存来进行有效率的缓存。在这种情况下，在达到1GB的缓存之后，更多的先期知识可能是有益的。

图63示出了随着时间的碎片化过程、以及与利用无限制缓存大小的基础LRU场景和最大场景相比的、使用256MB的缓存内存的每个所提出的算法的影响。在探究图表时，CBR和有限先期知识算法这两者的联合影响非常有效，从而在与数据从未碎片化的场景相比时保持结果极其靠近(8GBFK去碎片化与8GBFK最大相比较)。对于所有备份，当变化高于几个百分比时，存在仅一种情况。

另一方面，基于我能够收集到的踪迹，预测该提到的偏移针对数百或者数千个将来的备份是否能够保持在相同小的水平非常困难。即使这是不可能的，也会将碎片化的影响局限于没有利用该解决方案来示出的备份的小部分，并且事实上，可能不会被潜在的最终用户注意到。

当考虑图61和在图66中收集到的相同结果时，我们可以注意到一个重要的事实。由于使用了这两种算法，所以可以将内存需求降低8倍(从1024MB降低到128MB)，并且结果会使性能更高(11.35％-249.61％；平均为67.74％)。此外，针对总共6个数据集中的4个数据集，利用128MB的缓存产生的恢复带宽结果比在LRU情况下利用无限制内存更高，有5个数据集的结果非常接近(用户目录低了4.52％)，并且，由于高内存要求和内部流复本的具体模式，最后一个(邮件：低了65.22％)落后。

结果表明，许多数据集仅需要在如今通常被分配的内存中的仅一部分，并且仅有一些数据集可以受益于更大的内存量，但也只有在有效率地使用内存时才能受益。通常，在恢复过程期间，应当基于可用的内存、用户要求和每个数据流所请求的精确需要来分配适合的内存量，而不是动态地分配内存量。

<6.5可扩缩性>

最后但并非最不重要，由于当前的系统非常经常地使用10个或者更多个磁盘以便同时服务许多个流并且通过RAID或者纠删码[80]来恢复单个块[48、23、83]，所以可以使所有以上的结果进入另一个等级。在我的实验中，我对于整个流假设2MB预取，在以上的设置中，该预取意味着每磁盘仅200KB的预取。当使用最新的磁盘驱动器[71]时，这样小的预取意味着：与2MB(见图32)相比，从单个磁盘恢复时间提高了几乎6倍。

如之前已经在具有去重的系统的情况下提到的，更高的预取并不始终意味着更高的性能。当关注利用常见LRU算法(见图65)的结果时，即使是具有十个驱动器的速度(10x 175MB/s)，预取进一步增长到高于8MB(每驱动器800KB)仅在一种情况下并且仅针对未碎片化的数据会带来略微正面的影响。

当将利用先期知识的缓存算法纳入考虑时，结果则完全不同。在所有情况下，32MB预取带来改善几倍的结果，并且在两种情况(开发项目和通用文件服务器)下，甚至可以在更高的预取的情况下得到更好的结果。在单个情况下，仅仅(用户目录)16MB的预取略好于32MB。具体而言，当从最好LRU预取变为利用先期知识算法的最佳预取时，针对碎片化的数据可以获得额外的75％-390％(平均为184.23％)，并且对于未碎片化的数据可以获得另外的116％-933％(平均为396.77％)。与利用先期知识算法和单纯增加2MB的预取相比，预取大小可以将结果分别增加高达109％-379％(平均为254.72％)和132％-835％(平均为531.25％)。

利用以上的数字，增加预取大小看起来是一个非常令人感兴趣的选择。然而需要记得的是，这样的操作引入了更高的时延变化，这对于一些类型的使用而言可能非常重要。幸运的是，利用辅助存储系统，这不是个问题，因为在这种情况下，带宽最为重要并且可以容易地接受更高的时延。

对预取大小进行审视带来了另一种观察。大小越大，在碎片化数据与未碎片化数据之间的差异越明显。与LRU标准算法及其对于每个数据集的最佳预取大小一样，去碎片化可以带来大约20％-156％(平均为59.72％)的带宽增加，而对于具有其最佳预取大小的先期知识算法，相同增益可以达到44％-420％(平均为164.18％)。这样的结果表明，适当的去碎片化算法更为重要。

为了验证利用提出的CBR去碎片化算法对数据进行去碎片化的能力，我利用仅两种修改的参数执行了模拟。将预取大小设置为32MB(每驱动器3.2MB)，该预取大小看起来接近利用10个驱动器的最佳大小，并且将流上下文设置为80MB，以便保持与预取大小成比例。缓存大小仍然为256MB，其中先期知识被设置为8GB。在没有任何附加的调谐的情况下所实现的结果，实际上非常好。该算法能够获得36％-333％(平均为97.66％)的恢复带宽，最终仅比完全未碎片化的流低4％至19％(平均为8.88％)。在以上设置中难以去碎片化的唯一数据集是邮件。在这种情况下，最终的结果比未碎片化的流低34％，但与碎片化版本相比仍然显著增加了36％。

总而言之，我执行了又一个实验，该实验示出使用许多个磁盘以用于恢复以及在本文中引入的算法的重要性。假设使用了10个磁盘，我将两种算法与256MB的缓存进行比较：2MB预取LRU(表示在如今的系统[48、53]中常用的等级)与利用先期知识(8GB)和CBR去碎片化的32MB预取进行比较。所得到的最新备份的恢复带宽取决于数据集为从3.5倍上至高于16倍，其中平均为略高于8倍。仅以利用LRU的8MB预取来说——当考虑所有数据集和10个磁盘驱动器时其是最佳的，带来仅60％的增加。这示出，由于所提出的算法并且由于使用了许多磁盘驱动器，在关键恢复的情况下的可能的骤增可以非常显著。

<第7章相关工作>

<7.1与离线去重的比较>

市场上已经存在满足应对版本间碎片化的一些要求的一个简单的解决方案，并且这种解决方案被称为离线去重[74、62、61]，在第2.2.1节中将对其进行了描述。在其最简单的形式中，将来自当前备份的所有数据连续地存储在磁盘上，并且按照以下方式在后台进行去重：来自最新备份的块是用于从较旧备份消除重复的基础[61、45]。

因此，当前写入的流不具有碎片化，并且较旧的备份与其存期成比例地被碎片化。即使算法最可能不是设计用于处置碎片化，但是其对于消除最近备份中的碎片化非常有效。然而，由于对块进行去重通常比通过线缆发送该块并且将其存储在盘上快得多，所以离线去重系统可能会比在线去重系统更慢(或者需要更多的转轴和网络带宽以避免这样的问题)。

备份中复本的百分比取决于数据模式，但是基于由Wallace等人收集的超过10000个系统的特性，我们可以假设去重率的平均值处于10倍缩减的水平，这在平均的备份中引起复本中的大约90％。如第6.3.2节所阐释的，不在写入数据的情况下进行去重可以比首先写入数据然后在后台对其进行去重要快3倍。因此，对于离线去重，写入具有90％的复本的备份流花费300个时间单位，而使用具有在线去重的系统，只需要110个时间单位，即使这样的系统针对每个块进行了去重查询。因此，使用离线去重产生了大于170％的更多的备份窗口。这是肯定无法接受的，因为备份窗口通常无法被扩展很多。

上下文重写算法的想法是保持通过离线去重解决方案确保的去碎片化中的大部分并且提供能够应对在第2.2.1节中描述的其最大问题的灵活性。事实上，当修改算法的配置参数时，会重写所有的块并且会在后台消除所有的复本，从而使得这两种解决方案非常相似。另一方面，由于将重写的块的边界设置为5％，从而保留了在线复本消除的性能和其它方面，所以可以通过主要因素来改善碎片化改。

除了离线去重和在线CBR，还至少存在另一种其它选择：在后台执行基于上下文的重写，即离线，如在第5.4.6节中已经提到的。这样的解决方案根本不会影响到备份写入，但是其需要较长的件来完成读取碎片化的数据并且将这些数据重写入后台。另外，在完成块重写之前尝试的恢复仍然会受低带宽影响。

在图67中呈现了所有提到的替选方案的比较。此处需要注意的是，可以通过分阶段来改善这两种离线选择的存储消耗，所述分阶段即通过运行并行去除复本(或者重写复本中的一些)的过程但需要稍落后于备份写入过程。然而，分阶段需要更多的资源，诸如CPU、可用磁盘带宽和转轴。

<7.2碎片化测量>

Nam等人[52]已经引入了组块碎片化水平(CFL)以便使流的碎片化问题可视化。假设数据被存储在固定大小的容器(2MB或者4MB)中，该想法是将最优组块碎片化(将流的大小除以容器的大小)除以当前组块碎片化(在恢复期间读取的容器的实际数目)，从而将达到的结果的最大值限制为1。由此得到的数目与达到的性能成比例。不幸的是，该数目并未考虑到读取缓存的存在，该读取的缓存在测量恢复性能时非常重要并且该数目使实验不现实。

该算法的第二版本[53]确实将读取缓存的存在包括在了当前组块碎片化计算中，但是依然有一些其它缺陷。最大值1似乎是人为的限制，并且在存在高度良好缓存的内部流去重的情况下——如我的实验示出所述情况常常会发生，则不会反映实际的恢复性能。另一局限实际上在于对写入算法(容器的大小)连同其在缓存逐出算法中的使用一起的强烈依赖。在缓存中保持整个容器或者不保持容器对于任何一种缓存都似乎不是最优的选择，尤其是通常只有一些来自容器的块是必需的。另一方面，由于LRU缓存替换策略通常不是非常有效，所以这样的算法的影响较小——如果使用更有效的缓存逐出策略——诸如利用先期知识的缓存，则该问题会更加严重。

Lillibridge等人[48]实际上提出了称为“速度因子”的非常相似的指标，。该指标也是基于容器的数目，但是其是以略微不同的方式定义的，将1除以每兆数据读取的容器的数目。假设容器大小与CFL(4MB)相同，“速度因子”1等于CFL 0.25。当将这两种指标进行比较时，CFL看起来略好，这仅仅是因为值1明确地示出了系统的速度，而无去重并且无碎片化。另一方面，不以任何方式对“速度因子”进行限制，即使在内部流去重的影响是积极的时也示出实际值。不幸的是，这样的特征仅仅是理论上的，因为在实验中使用的算法不允许“速度因子”的值为4(等于CFL 1.0)及以上，即使对于使用了无限制的缓存内存也是如此。对两种算法的一些局限性仍然是太过于依赖在备份过程期间创建的容器大小。

我提出的指标“％的恢复带宽无复本”与以上指标实际上非常相似但具有一些修改(见图68中的对比)。首先，其名字清楚地表明了它的含义，使其使用起来非常直观。其次，其不以任何方式限制结果，即使是在其比在不具有去重的系统中更好的情况下，也能够非常良好地预测输出性能。再次，其高度独立于写入算法并且不依赖于所使用的容器大小，这可以有助于使其可用在较大范围的系统以便利用不同的预取值进行试验。当然，也可以容易地对其进行限制以反映与固定容器大小的指标实际上相同的行为。最后但并非最不重要的因素是模拟所使用的缓存逐出策略。我的实验示出，毫无疑问该因素在测量碎片化时是一种极其重要的因素，并且对达到的结果可以具有非常大的影响。

<7.3去碎片化算法>

最近，改善具有去重的存储系统的读取性能的话题在发表的论文中很流行。Lillibridge等人[48]提出的解决方案涉及被称为“容器限顶(capping)”的技术，该技术可以被视为一种去碎片化。通过确保仅从有限数目的容器进行恢复，该解决方案良好地改善读取带宽，但是仅将示出的结果与作者[44]设计的原始算法进行了比较，该原始算法相当差并且由于设计的原因导致碎片化程度更高(通过对结果进行分析，当将该结果与无去重的简单系统相比时该结果的恢复带宽差了12-44)。不幸的是，未与无版本间碎片化所实现的恢复带宽进行比较，也未与具有无限制的缓存的算法进行比较，该比较会非常令人感兴趣并且会使结果至少可部分与本文所提到的结果相比较。由于未进行该比较，所以无法确定内部去重的水平以及其对最终结果的影响，如在实验中表明的，这些最终结果有可能非常重要。从这些图中我们可以得到的一个信息是：通过将限顶设置为10(达到在本文中分析的所有选择的最高恢复带宽)，该算法实现了不具有去重的系统中有可能实现的带宽的50-90％(假设速度因子4等于100％)。该结果听起来可能还算良好，但仅在我们不考虑对累积去重因子的负面影响的情况下，在这样的设置中该累积去重因子等于17-50(取决于数据集)。该成本非常高并且导致更低的写入带宽，这在文本中尚未提到。与Lillibridge的研究相比，本文中提到的所有算法都未改变去重率，并且仅有一种算法略微降低了写入带宽。除了这些算法之外，本研究还示出了碎片化问题对令人感兴趣的长期踪迹(涵盖了甚至两年的时期)的重要性，其是难以找到的。不幸的是，该踪迹最终无法用于其它研究，这使我无法直接对结果进行比较。

Nam等人提出了另一种确保所需读取性能的方式。[53].其基本想法是使用组块碎片化水平(Chunk Fragmentation Level)[52、53]指标来监视在写入期间的模拟读取性能并且当该水平低于一些限定的阈值时实现选择性的去重。由于其示出CFL是一种做到这点的好指标，所以这样的算法在存储数据的同时保证了一些预定义的读取性能。在实践中，该结果是以适度高的成本来达到的。由于选择性去重仅在部分时候有效，所以省略了流中的可以大幅改善碎片化的一些地方，而需要以完备的序列来存储块则使得再次存储了很多不必要的重复块。基于以上观察，在非常低的备份带宽(在确保用于恢复的CFL＝0.6的同时，存在甚至70-90％的下降)的情况下，我仅可以假设这样的块的该水平较高，因为该文并未提到算法对去重率的影响。另一方面，本文提出的算法未引入额外的存储消耗，并且试图以不高于该用户定义的成本的成本来解决碎片化问题。这样的方法有效率得多，因为我试图以可能的最小成本来改善碎片化。使某个选择具有确保的性能也是可能的(一种简单的方式是：将当前重写效用设置为某个固定值；或者一种复杂的方式是：通过在写入期间模拟恢复性能来设置当前重写效用)，但是付出的代价是可变的写入带宽，其可能是不可接受的。这样的解决方案仍然会比作者所提出的解决方案更好，这是因为首先重写的块会是引入最高碎片化的块。

RevDedup[57]是一种通过执行运行中逆向去重来应对碎片化的系统。在存储这样的块之后，立即定位并且去除较旧的副本。令人感兴趣的方法还被用于处置Null(补零)块，在虚拟机镜像中可以经常发现所述Null块。在这样的情况下，服务器跳过磁盘写入，并且在必要时在运行中生成Null数据。不幸的是，整个系统是针对虚拟机镜像设计的，其中许多解决方案——诸如固定块大小和大片段(4MB)通常不适用于存储系统。该解决方案在高度改善恢复带宽方面是成功的，但是另一方面，即使利用灵巧的Null块处置，与常规去重相比该系统也受低得多(30-65％)的备份吞吐量的影响，并且达到了较低的去重率。

Srinivasan等人[75]描述了与在主存储中发现的碎片化所存在的非常相似的问题。iDedup提出的解决方案是通过存储的块在磁盘上保持最小序列长度来分摊寻道。在这种情况下，任务更加复杂，这是因为对于主系统而言时延是最重要的因素中的一个。各种结果示出了平均请求大小的增加以及更好的客户端响应时间，但是差别不是很大。同样，未测量恢复带宽(有可能是因为该系统的用途不同)。另一方面，即使对于主存储系统，去重率下降到30-50％的程度也似乎较为明显。

<7.4缓存>

前向组装区域(Forward assembly area)[48]是除了容器限顶之外的由Lillibridge等人提出的第二种技术，旨在通过在恢复开始时使用备份的配方来帮助实现更好的缓存内存使用(与先期知识相似)。在最简单的情况下，作者利用为读取的分片所分配的必要的内存来将完整备份恢复为M字节的分片，所分配的内存被称为前向组装区域。为了恢复单个M字节的分片，他们首先将配方的对应部分读取到内存缓冲区中，并且确定需要哪些组块来填充所要求的字节范围。每次对组装区域中的最早没有填充的组块点进行局部化时，在填充组件中需要组块形成该容器的所有部分的同时恢复相对应的容器。在完成该过程之后，可以向用户返回数据，并且可以清空该组件区域以读取下一个M字节的分片。

令人关注的事实是：该解决方案仅对高度碎片化的数据有效(不是限制或者高限制等级)，按照其的定义方式，在我的实验中也可以观察到这点。不幸的是，利用更合理的限顶值(10、15、20——如本文所定义的)，这使得算法并非真的有用。此处的主要问题是，整个前向区域需要预留内存，即使在大多数时间并不使用该内存(1GB的前向组装区域需要1GB的RAM)。该方法显著地限制了前向组装区域的最大可能的大小，因此使该算法对于未碎片化的流不太有效。与前向组装区域相比，具有本文中提到的先期知识的缓存对于1GB的先期知识要求甚至低至1.62MB的内存，并且其非常有效地使用所有的缓存以仅用于保持在将来实际会需要的块。在图54中可以看到实际差别，在图54中利用512MB的缓存和512MB的先期知识看起来与512MB的前向组装区域非常相似(不同之处在于，利用我的算法在整个流中可以将再次出现的块保持在内存中，而利用前向组装区域，不再次读取块的保证仅针对该区域的大小)。因此，用户可以利用比先期知识缓存小了几倍的内存成本来得到更高的恢复带宽，。

对除了以上[52、53、41]之外的备份系统中的碎片化的所有研究仅使用LRU缓存来测量达到的结果并且验证所提出的解决方案的有效性。另外，Wallace等人[79]对生产系统中的备份工作负载进行了广泛研究，该生产系统在恢复最终备份时向LRU读取缓存报告命中率。在示出的图中，我们可以观察到附加缓存内存的影响。不幸的是，当关注从128MB开始上至32TB的唯一合理选择(容器级缓存)时，结果中的大多数看起来非常相似并且无法按照要求的精度来读取，这使对于我们的目的而言这样的数据表示的有用性非常低。注意，在利用4MB容器没有存取重复流的情况下，期望的流命中率是99.8％(大小为8KB的每500个块读取1次)，而99.6％示出了已经多于两倍的I/O操作，从而将恢复带宽减少了一半。同样，在已良好缓存的内部流复本的情况下，缓存命中率可以高于99.8％水平。

在[5]中，B'el'ady示出了当使用块基准(block reference)的完整序列时通过预运行程序而提供的最优缓存替换策略。该算法最初设计用于分页(paging)，但是其可以被用在单个读取大小(来自一些慢设备)和最小缓存替换大小相等的情况。在相似的假设下，Cao等人[14]对集成式预取和缓存策略执行了研究，给出了每种最优解决方案需要遵守的四个规则。不幸的是，由于与B'el'ady的算法对于在备份系统中进行流存取的情况不是最优的相同原因，他们未直接应用这些规则。假设该预取包含一次读取的许多个块并且可以针对每个单块操作的缓存逐出策略，应当计算再次读取以供去除每个候选的潜在成本。由于是分批对块进行读取，所以应当始终考虑到在一个批次中读取的所有块来计算该成本，并且应当将该成本除以实际需要的块的数目。一方面，这样的方法可能允许最优使用专门用于数据的缓存，但是另一方面，可能会要求另外存储具有未知最终结果的元信息。如我的实验所示，具有使用简化的附加信息的有限先期知识的缓存很有效，并且在许多情况下，实际上会产生与最大性能非常接近的性能(利用无限制的缓存大小实现)。

<7.5其它相关的工作>

有一些论文研究了改善元数据读取以用于更快的复本消除。Zhu等人[83]描述了一种利用布隆过滤器和面向流的元数据预取的解决方案，而Lillibridge等人[44]认为由于更小的内存消耗所以稀疏索引(消除仅在先前选择的多个大片段内的复本)会更好。这些解决方案假设流式写入模式，而SSD可以被用于消除随机复本[21、49]。这样的方法使碎片化问题更严重，这是因为可以检测到更多精细粒化的复本。另外，以上技术全部都不能解决读取碎片化数据的问题，并且在所有情况下，碎片化随着后续备份而加剧。令人关注的事实是，CBR去碎片化算法通过使对去碎片化流的数据和元数据的存取更连续，作为副作用而提高了一些前面的解决方案的有效性。

如果我们放宽对去碎片化解决方案的不降低去重有效性的要求，我们可以试着仅在数据的子集内去重，从而潜在地减少碎片化。除了稀疏索引之外，这样的方法还有可能利用极端区间划分(extreme binning)[7]，利用大片段相似性——诸如ProtectTier[3]、子组块去重[69]，以及利用将去重局限于节点中的一个或者节点的子集的多节点系统——诸如Pastiche[20]和DataDomain全局扩展[22、28]。不幸的是，即使我们考虑先前备份的非常少的(2-3个)片段来对当前片段再次去重，这些片段在磁盘上也可能已经不是顺序的，这是因为它们也可能包含来自其它较旧的片段的复本。

一些供应商——诸如EMC——试图利用时间和资源消耗内务处理过程[46、83]来应对碎片化。对该过程的描述尚未公开，但是一种可能的方式是在后台选择性地重写复本的子集，即按照与我们的CBR方法相似的方式，不同的是离线进行。在第7.1节中给出了有关该算法的更多信息。其它系统——诸如HYDRAstor[23、55]——使用更大的块大小(64KB)，这降低了碎片化问题的严重程度但是也可能会降低去重。然而，大的块大小也促进了全局去重，总体而言这提高了去重率。最后，我们可以通过利用逻辑对象进行去重来消除碎片化。在EMC Centera[27]的早期版本中，去重的单位是整个文件，这对于Centera的目标市场——即存档有效，但是对于备份则不是正确的解决方案，这是因为文件修改使这样的去重无效。

更重要的是，以上解决方案都未提到对先期知识的使用，当涉及备份解决方案时，该先期知识是易于获得的。如我的实验所示，当涉及所使用的恢复性能和缓存内存的效率时，该附加信息产生了显著的差异。

<第8章结论>

<8.1概要>

在本文中，我描述了在具有去重的备份系统中的数据碎片化问题并且针对该问题的两个不同方面提出了解决方案。另外，在具有和不具有引入的算法的情况下我对由去重导致的不同种类的碎片化对备份恢复带宽的影响进行了量化。为了支持我的结果，我对从用户收集的真实备份踪迹进行了大量的实验。

该问题非常严重，并且在假设使用单个驱动器并且与不具有去重的系统进行比较的同时，取决于每个数据集的特性，其可能会导致大于4倍的恢复带宽下降(包括版本间碎片化和内部流碎片化)。当使用了更多转轴时，应当预期得到甚至更大的下降。由于我的实验是在每个集合仅具有7-50个备份的6个真实备份踪迹集合的情况下驱动的，随着跨越多月或者多年的备份，该问题仍然有高可能性进一步严重。最后，在具有在线去重的最普及的系统中，碎片化对最新的备份——也是最有可能被恢复的备份——影响最大。为了解决该问题，我已经提出了应对碎片化的两个不同方面的两个算法。

第一个方法是具有有限先期知识的专用缓存，并且旨在解决由单个备份中存在的许多复本导致的内部流碎片化。由于专门针对备份系统的其设计，所以该解决方案使用已经与每个备份一起存在的先期知识，以便提供对缓存内存——专用于要重复使用的实际数据的缓存内存(简称为缓存)——的有效使用。而且，取决于内存限制和流特性，该算法将内部流碎片化所导致的大多数负面影响转换为正面影响。这是通过保持在内存中多次使用的块来实现的，常常产生比不具有去重的系统更好的性能，其中数据被顺序地安置。

因此，在使用先期知识时，与标准LRU方法相比，在128MB至1GB缓存配置中，平均恢复带宽增加了61％至87％。当将仅具有2GB的先期知识的128MB的选择与1GB的LRU缓存相比时，也很好地示出了所使用的内存的有效性。在这种情况下，即使即利用几乎8倍更低的内存，但是所提出的算法仍然实现了平均为16％的更好的恢复带宽。另一令人关注的事实是，利用256MB的内存，8GB的先期知识能够提供的恢复效果常常与利用无限先期知识所能提供的恢复效果几乎一样高。而且，6种情况中的4种中：结果与利用无限制缓存大小所实现的结果几乎完全相同。

被称为基于上下文的重写的第二个算法直接针对由随时间缓慢变化的相同文件系统的许多备份导致的版本间碎片化问题。通过在备份期间重写不多于所有块的5％，该算法改善了最新备份的恢复带宽，同时使很少读取的较旧的块的碎片化加剧。在后台去除重写的块的旧副本，例如在周期性删除和空间回收过程期间，在具有去重的存储系统中要求该过程。

我的踪迹驱动式模拟已经表明，重写一些所选择的块(平均为1.58％)略微(1-9％)降低了最大写入性能，但是实际上，消除了最新的备份的恢复速度降低，从利用LRU缓存的最大带宽的12-51％至最多7％(平均为2.6％)。

由于这两种提出的算法解决数据碎片化的不同方面，我已经将这两种算法进行了组合以便实现甚至更好的效果。实际数字显示出比标准LRU高了16％至388％的恢复带宽，其中平均高了140％(这两种算法都使用了256MB缓存，但是组合后的版本针对先期知识结构具有额外的13MB)。结果示出，这些算法彼此互补，这是因为该效果甚至比在仅仅加上由这些算法中的每一个实现的增益之后可预期的效果更好(平均提高可达99％)。而且，由于有效的块重写和高效的内存使用率，仅具有128MB的缓存的组合的算法提供了比标准LRU更好的效果，其中甚至无限制的可用的缓存并且在保持合理的性能的同时，为所使用的内存的其它限制留出了空间。这很重要，因为针对读取的每个流都要求示出的内存，而在关键恢复的情况下，可以立即恢复流中的许多。

当假设在该系统中仅有单个盘驱动器时，所提出的算法非常有效，但是，更令人关注的是它们在更多真实生活场景中的行为，在该场景中从许多个硬盘驱动器立即执行对一个流的恢复。实验示出，在这样的环境中该问题达到另一个等级，使得恢复甚至更加无效。幸运的是，通过有效地利用设置并且达到3.5-16倍的更高带宽(平均为8倍)，组合式算法也在这种场景中显示出了它们的长处。

即使数据碎片化问题已经存在了一段时间[83、62、61、63、46、45、81]，但是多年来，针对该主题尚未有发表的文章。试图深入该话题的第一篇论文出现在2012年[75、53、41]，在2013年[48、57]又发表了几篇。这表明，该主题已经得到社会的越来越多的关注，并且有可能仍然需要研究以清楚地理解该问题并且提供足够灵活以与不同方法一起使用的解决方案。我相信，我的论文在该方向上迈出了重大的一步，如下：(1)详细分析了该问题，并且指明了观察到的减速的三种原因；(2)提出了两个独立的算法来解决该问题的最严重的方面；以及(3)提供了各个实验的结果，使社区能更好地理解在具有去重的备份系统中的数据碎片化问题。

<8.2将来的工作>

<8.2.1完善在恢复期间的内存划分>

如第4.5章所讨论的，当涉及到不同的数据集甚至是在单个流的恢复过程内，在实际缓存与先期知识之间的固定内存划分不是最优选择。此处的解决方案可以是动态内存划分。该想法是在剩余的内存未被实际数据完全占用时扩展先期知识，并且在没有足够的空间来保持读取的并且在将来会需要的块时减少先期知识。关键在于恒定地保持如下状态：其中可以在保持几乎100％利用内存的情况下，将所有会在先期知识中找到的读取的块存储在内存中。

该想法通常极为简单，但是此处的难处是在分布式系统中始终存在每个这样的操作的时延。这在提供元数据的层与缓存自身之间需要一些使划分更平滑的专用算法和专用通信接口。虽然如此，这样的算法也应当能够实现比本文中提出的固定内存分配更加有效的缓存使用率。

<8.2.2最优缓存内存使用率>

由于缓存的量是固定的，所以在涉及到页面替换策略时，所提出的逐出在将来最长时间内不会使用的块的算法不像B'el'ady的最优算法[5]一样是最优的。在后一种情况下，实际上将页面视为独立的单元，其在页面故障的情况下可以被删除或者单独地读取，使得具有备份流中的数据块的情况不同。

如在备份内，从读取的时间来看，相邻块在逻辑上通常彼此相连，当涉及到内存管理时，这对于利用该观察结果有利。该想法是不仅仅关注有必要进行逐出时与块的距离，实际上还要关注每个操作的成本。这样做时，看起来不同于在将来将位于流中的块保持存储在N、N+1位置，将它们保持在位于N+2和N+3位置实际上更好。这样的场景可能发生在可利用仅一个I/O来从磁盘读取前两个块而对于后面的块需要两个I/O时。

难以预测这样的解决方案在提高带宽和/或甚至提高小内存量的更有效使方便的潜力。一方面，在我的实验中，利用256MB的内存6个数据集中的4个已经实现了最大的可能带宽(与具有无限制缓存大小的情况相似)，但是另一方面，当涉及用户目录和邮件时，仍然具有潜力。当然，在所有情况下，由于实际最优实施方式，所以可能的是，甚至更小的内存量也会提供与最大内存量——当不存在内存限制时可用的内存量——非常接近的带宽。

<8.2.3变量大小预取>

另一种提高总体恢复性能的更一般的提议是使用变量预取大小。该想法是基于事先已知的或者在流恢复期间收集到的一些流特性来修改预取大小。通过该步骤，例如，当数据请求或多或少随机地分散在磁盘上时可以使用非常小的预取，或者当按照精确连续的顺序请求数据时，可以使用非常大的预取。即使该算法在请求的数据的顺序可以非常不同或者可以相对于磁盘上的每个块替换而事先知道时可能非常有用，但是其在备份系统的情况下似乎具有有限的可使用性。此处的主要问题是，其实际上并未能解决潜在的碎片化问题，而仅仅是试图通过使用更小的预取来遮盖该问题，而更小的预取仍然导致了恢复劣化。

<8.2.4保留策略和删除实验>

仍然需要从影响最新备份的恢复性能的因素方面进行审视的感兴趣区域是保留策略。此处的第一种想法是验证备份的频率(每日&每周&每月)及其对碎片化水平连同利用CBR去碎片化实现的结果的影响。第二种想法是验证在系统中保持的一个备份集的先前版本的数目的影响(假设在一个实验内备份频率是固定的)。一方面，具有更多的数据也使得更难读取实际需要的块，但是，另一方面，仅仅删除旧版本并没有使当前备份改变在磁盘上的位置。此处的解决方案可以是在属于相同流的数据之间设置一些智能的串接机制。

<8.2.5对CBR算法的可能的扩展>

当涉及基于上下文的重写算法时，将来的工作可以探索一下问题：

·当碎片化较严重时，允许略微减少去重；

·在写入期间利用先期知识模拟缓存算法(实际上与恢复所用的方法相同或者相似)；

·在选择最优当前效用阈值的同时，应用在先前的备份期间收集到的统计数据；

·每第n备份执行一次CBR去碎片化以便节省写入带宽；

·当考虑重写特定块时，将该块所在的其它流纳入考虑。

即使当前CBR算法执行去碎片化非常有效，最优结果是留下了不到7％，但是以上扩展可能会缩小该差距甚至进一步减少对于每个备份的写入带宽成本。

<8.2.6全局碎片化>

需要进一步分析的碎片化的最后一个方面是安置在一个备份系统中的不同数据集之间存在的全局碎片化。在第3.2.3节中，我已经描述了该问题以及针对实际解决方案的一些可能的方法。在达到数据去重的最大效率的同时，从为任何现有的系统以及安置在一起的不同数据集的任何组合提供解决方案这方面来看，碎片化的本方面似乎最为复杂。在许多不同的使用模式中，全局复本的数目以及其对去重率和附加碎片化的量二者的影响有很大的不同。在恢复性能的优先级极高的系统的情况下，将去重范围局限于相同流的先前版本可能是一种合理的选择。在先前的节中提出的对CBR算法的扩展中的一些也可以有助于全局碎片化的该方面。

<附录>

可以将上面所公开的整个或者部分示例性实施例描述为以下附录。下面，将对根据本发明的存储设备概述等进行描述。然而，本发明不限于以下配置。

(附录1)

一种存储设备，包括：

数据存储部，所述数据存储部存储经去重的块数据；

临时数据存储部，所述临时数据存储部临时存储从所述数据存储部获取的块数据；

数据检索控制部，所述数据检索控制部检索由所述数据存储部存储的所述块数据，将所述块数据存储到所述临时数据存储部中，并且从所述临时数据存储部检索所述块数据；以及

临时数据控制部，所述临时数据控制部控制由所述临时数据存储部存储的所述块数据的存储状态，

所述存储设备还包括检索轮次信息存储部，所述检索轮次信息存储部存储检索轮次信息，所述检索轮次信息是关于所述块数据的检索轮次的信息，其中：

数据检索控制部使得所述临时数据存储部基于从所述检索轮次信息存储部获取的所述检索轮次信息来存储从所述数据存储部获取的所述块数据；以及

所述临时数据控制部基于所述检索轮次信息来控制在所述临时数据存储部中的所述块数据的所述存储状态。

(附录2)

根据附录1所述的存储设备，其中，通过基于所述检索轮次信息来删除由所述临时数据存储部存储的所述块数据，所述临时数据控制部控制在所述临时数据存储部中的所述块数据的所述存储状态。

(附录3)

根据附录1或者2所述的存储设备，其中，通过依据与目标块数据基于所述检索轮次信息的检索轮次的距离程度来删除所述块数据，所述临时数据控制部控制在所述临时数据存储部中的所述块数据的所述存储状态，所述目标块数据是待由所述数据检索控制部检索的块数据。

(附录4)

根据附录1至3中任一项所述的存储设备，其中：

所述数据检索控制部使得所述临时数据存储部存储基于所述检索轮次信息的块数据轮次信息，所述块数据轮次信息是将用于识别所述块数据的块数据识别符与表示待检索由所述块数据识别符指示的所述块数据的检索轮次的轮次信息相关联的信息；以及

所述临时数据控制部通过使用所述块数据轮次信息来控制在所述临时数据存储部中的所述块数据的所述存储状态。

(附录5)

根据附录4的存储设备，其中，被包含在所述块数据轮次信息中的所述块数据识别符是基于由所述块数据识别符指示的所述块数据的内容来计算的散列值的一部分。

(附录6)

根据附录4或者5所述的存储设备，其中，被包含在所述块数据轮次信息中的所述轮次信息是表示区段的轮次的信息，所述区段是通过将基于所述检索轮次信息来执行的一系列检索过程按照给定大小划分成多个区段而获得的。

(附录7)

根据附录1至6中任一项所述的存储设备，其中：

所述数据检索控制部被配置为，在所述临时数据存储部没有存储作为待检索的目标的块数据的情况下，从所述数据存储部检索多个块数据，并且使得所述临时数据存储部存储所述多个块数据，所述多个块数据包括作为待检索的所述目标的块数据并且在物理区域中是连续的；以及

所述临时数据控制部基于所述检索轮次信息来从所述数据存储部获取的所述多个块数据当中删除未被确定为待排程进行检索的块数据。

(附录8)

根据附录1至7中任一项所述的存储设备，其包括：

数据划分部，所述数据划分部将写入目标数据划分为多个块数据；

块检测部，所述块检测部检查是否已经将通过所述数据划分部作出的划分而获得的所述块数据中的每一个存储在所述数据存储部中；以及

数据写入部，所述数据写入部将通过所述数据划分部作出的划分而获得的所述块数据中的每一个存储到所述数据存储部中，并且在存储具有与已经存储在所述数据存储部中的块数据相同内容的其它块数据时，使得已经存储在所述数据存储部中的该块数据被参考作为该其它块数据，其中：

所述块检测部检测共同率，所述共同率表示在通过所述数据划分部作出的划分而获得的所述块数据当中的所述写入目标数据中配置预定范围的多个连续块数据与已经按顺序被存储在所述数据存储部中的预定范围内的多个块数据之间的共同部分的比率；以及

所述数据写入部依据所述块检测部所检测到的所述共同率来将通过所述数据划分部作出的划分而获得的所述块数据重新存储到所述数据存储部中。

(附录9)

根据附录8所述的存储设备，其中，所述数据写入部将在所述写入目标数据被划分时出现的彼此完全相同的块数据当中在所述写入目标数据中首次出现的块数据作为目标，以用于写入所述数据存储部中。

(附录10)

根据附录9所述的存储设备，其中，所述数据写入部使用布隆过滤器来判断所述块数据是否首次出现在所述写入目标数据中。

(附录10-1)

根据附录8至10中任一项所述的存储设备，其中，所述数据写入部被设置以使得，在所述写入目标数据当中重写的块数据的量相对于已经被存储在所述数据存储部中的数据的量的比率变得等于或者小于预设比率，所述重写的块数据是依据所述块检测部所检测到的所述共同率来被重新存储到所述数据存储部中的块数据。

(附录11)

一种包括指令的计算机程序，所述指令用于使得信息处理设备实现以下装置——所述信息处理设备包括数据存储部，存储经去重的块数据；临时数据存储部，临时存储从所述数据存储部获取的块数据；以及检索轮次信息存储部，存储作为关于所述块数据的检索轮次的信息的检索轮次信息：

数据检索控制装置，所述数据检索控制装置用于检索由所述数据存储部存储的所述块数据，将所述块数据存储到所述临时数据存储部中，并且从所述临时数据存储部检索所述块数据；以及

临时数据控制装置，所述临时数据控制装置用于控制由所述临时数据存储部存储的所述块数据的存储状态，其中：

所述数据检索控制装置使得所述临时数据存储部基于从所述检索轮次信息存储部获取的所述检索轮次信息来存储从所述数据存储部获取的所述块数据；以及

所述临时数据控制装置基于所述检索轮次信息来控制在所述临时数据存储部中的所述块数据的所述存储状态。

(附录12)

根据附录11所述的计算机程序，其中，通过基于所述检索轮次信息来删除由所述临时数据存储部存储的所述块数据，所述临时数据控制装置控制在所述临时数据存储部中的所述块数据的所述存储状态。

(附录13)

根据附录11或12所述的计算机程序，其中，通过删除其检索轮次与目标块数据基于所述检索轮次信息的轮次远离的块数据，所述临时数据控制装置控制在所述临时数据存储部中的所述块数据的所述存储状态，所述目标块数据是待由所述数据检索控制装置检索的块数据。

(附录14)

一种信息处理方法，所述方法包括：

获取检索轮次信息，所述检索轮次信息是关于块数据的检索轮次的信息；

使得临时存储设备基于所获取的检索轮次信息来存储从存储设备获取的块数据；以及

基于所述检索轮次信息来控制在所述临时存储设备中的所述块数据的存储状态。

(附录15)

根据附录14所述的信息处理方法，包括：通过基于所述检索轮次信息来删除由所述临时数据存储设备存储的所述块数据，控制在所述临时数据存储设备中的所述块数据的所述存储状态。

(附录16)

根据附录14或15所述的信息处理方法，包括：通过删除其检索轮次与目标块数据基于所述检索轮次信息的轮次远离的块数据，控制在所述临时存储设备中的所述块数据的所述存储状态，所述目标块数据是待检索的块数据。

示例性实施例和附录中公开的程序被存储在存储设备中或者被记录在计算机可读的记录介质中。例如，记录介质是便携式介质，诸如柔性盘、光盘、磁光盘和半导体存储器。

虽然上面已经参照示例性实施例来对本发明进行了描述，但是本发明不限于上面描述的示例性实施例。在本发明的范围内，可以按照本领域的技术人员可以理解的各种方式来改变和修改本发明的配置和细节。

附图标记描述

1，6 存储系统

11 元数据存储部

12 磁盘设备

13 恢复管理部分

14 缓存内存

141 块数据轮次信息

142 数据信息

15 缓存内存控制部

66 数据划分部

67 块检测部分

68 数据写入部

2 加速器节点

3 存储节点

4 备份系统

5 备份目标设备

70 数据集

71 划分数据

72 冗余数据

8 存储设备

81 数据存储部

82 临时数据存储部

83 数据检索控制部

84 检索轮次信息存储部

85 临时数据控制部