平码五不中公式规律
  • / 127
  • 下载费用:30 金币  

存储设备、程序和信息处理方法.pdf

关 键 ?#21097;?/dt>
存储 设备 程序 信息处理 方法
  专利查询网所有资源均是用户自行上传分享,仅供网友学习交流,未经上传用户书面授权,请勿作他用。
摘要
申请专利号:

CN201580041132.1

申请日:

2015.06.23

公开号:

CN106662981A

公开日:

2017.05.10

当前法律状态:

实审

有效性:

审中

法?#19978;?#24773;: 实质审查的生效IPC(主分类):G06F 3/06申请日:20150623|||公开
IPC分类号: G06F3/06 主分类号: G06F3/06
申请人: 日?#38236;?#27668;株式会社
发明人: 米夏尔·卡齐马尔奇克; 切查利·杜布尼基
地址: 日本东京
优?#28909;ǎ?/td> 2014.06.27 US 62/018,122
专利代理机构: 中原信达知识产权代理有限责任公司 11219 代理人: 韩峰;孙志湧
PDF完整版下载: PDF下载
法律状态
申请(专利)号:

CN201580041132.1

授权公告号:

|||

法律状态公告日:

2017.06.06|||2017.05.10

法律状态类型:

实质审查的生效|||公开

摘要

一种存储设备,具有:数据存储部,其存储经去重的块数据;临时数据存储部,其从数据存储部获取的块数据;数据检索控制部,其检索由数据存储部存储的块数据,将所述块数据存储到临时数据存储部中,并且从临时数据存储部检索所述块数据;以及临时数据控制部,其控制由临时数据存储部存储的块数据的存储状态。所述存储设备还包括检索轮次信息存储部,其存储检索轮次信息,该信息是关于块数据的检索轮次的信息。数据检索控制部使得所述临时数据存储部基于从检索轮次信息存储部获取的检索轮次信息来存储从所述数据存储部获取的块数据,并且临时数据控制部基于所述检索轮次信息来控制在临时数据存储部中的块数据的存储状态。

权利要求书

1.一种存储设备,包括:
数据存储部,所述数据存储部存储经去重的块数据;
临时数据存储部,所述临时数据存储部临时地存储从所述数据存储部获取的块数据;
数据检索控制部,所述数据检索控制部检索由所述数据存储部存储的所述块数据,将
所述块数据存储到所述临时数据存储部中,并且从所述临时数据存储部检索所述块数据;
以及
临时数据控制部,所述临时数据控制部控制由所述临时数据存储部存储的所述块数据
的存储状态,
所述存储设备还包括检索轮次信息存储部,所述检索轮次信息存储部存储检索轮次信
息,所述检索轮次信息是关于所述块数据的检索的轮次的信息,
其中:
所述数据检索控制部使得所述临时数据存储部基于从所述检索轮次信息存储部获取
的所述检索轮次信息来存储从所述数据存储部获取的所述块数据;以及
所述临时数据控制部基于所述检索轮次信息,来控制在所述临时数据存储部中的所述
块数据的所述存储状态。
2.根据权利要求1所述的存储设备,其中,
通过基于所述检索轮次信息来删除由所述临时数据存储部存储的所述块数据,所述临
时数据控制部控制在所述临时数据存储部中的所述块数据的所述存储状态。
3.根据权利要求1或2所述的存储设备,其中,
基于所述检索轮次信息,通过依据与目标块数据的检索轮次的距离程度删除所述块数
据,所述临时数据控制部控制在所述临时数据存储部中的所述块数据的所述存储状态,所
述目标块数据是待由所述数据检索控制部检索的块数据。
4.根据权利要求1至3中的任一项所述的存储设备,其中:
所述数据检索控制部使得所述临时数据存储部基于所述检索轮次信息来存储块数据
轮次信息,所述块数据轮次信息是将用于识别所述块数据的块数据识别符与表示由所述块
数据识别符指示的所述块数据的检索轮次的轮次信息相关联的信息;以及
所述临时数据控制部通过使用所述块数据轮次信息,来控制在所述临时数据存储部中
的所述块数据的所述存储状态。
5.根据权利要求4所述的存储设备,其中,
被包含在所述块数据轮次信息中的所述块数据识别符是基于由所述块数据识别符指
示的所述块数据的内容来计算出的散列值的一部分。
6.根据权利要求4或5所述的存储设备,其中,
被包含在所述块数据轮次信息中的所述轮次信息是表示区段的轮次的信息,所述区段
是通过将基于所述检索轮次信息执行的一系列检索过程按照给定大小划分成多个区段而
获得的。
7.根据权利要求1至6中的任一项所述的存储设备,其中:
所述数据检索控制部被配置为:在所述临时数据存储部没有存储作为待被检索的目标
的块数据的情况下,所述数据检索控制部从所述数据存储部检索多个所述块数据并且使得
所述临时数据存储部存储所述多个块数据,所述多个块数据包括作为待被检索的所述目标
的块数据并且在物理区域中是连续的;以及
所述临时数据控制部从被从所述数据存储部获取的所述多个块数据当中,基于所述检
索轮次信息来删除未被确定为待排程进行检索的块数据。
8.根据权利要求1至7中的任一项所述的存储设备,其包括:
数据划分部,所述数据划分部将写入目标数据划分为多个块数据;
块检测部,所述块检测部检查是否已经将通过由所述数据划分部进行划分而获得的所
述块数据中的每一个存储在所述数据存储部中;以及
数据写入部,所述数据写入部将通过由所述数据划分部进行划分而获得的所述块数据
中的每一个存储到所述数据存储部中,并且在存储与已经被存储在所述数据存储部中的块
数据具有相同内容的其它块数据时,使得已经被存储在所述数据存储部中的该块数据被参
考作为该其它块数据,
其中:
所述块检测部检测共同?#21097;?#25152;述共同?#26102;?#31034;在通过由所述数据划分部进行划分而获得
的所述块数据当中的构成所述写入目标数据中的预定?#27573;?#30340;多个连续块数据与已经按顺
序被存储在所述数据存储部中的预定?#27573;?#20869;的多个块数据之间的共同部分的比?#21097;?#20197;及
所述数据写入部依据由所述块检测部所检测到的所述共同?#21097;?#26469;将通过由所述数据划
分部进行划分而获得的所述块数据重新存储到所述数据存储部中。
9.根据权利要求8所述的存储设备,其中,
所述数据写入部将在所述写入目标数据被划分时出现的彼此相同的块数据当中的在
所述写入目标数据中?#29366;?#20986;现的块数据作为目标,以写入所述数据存储部中。
10.根据权利要求9所述的存储设备,其中,
所述数据写入部使用布隆过滤器来判断所述块数据是否?#29366;?#20986;现在所述写入目标数
据中。
11.一种包括用于信息处理设备的指令的计算机程序,所述信息处理设备包括:
数据存储部,其存储经去重的块数据,
临时数据存储部,其临时地存储从所述数据存储部获取的块数据,以及
检索轮次信息存储部,其存储作为关于所述块数据的检索的轮次的信息的检索轮次信
息,
所述指令用于使得信息处理设备实现下述各装置:
数据检索控制装置,所述数据检索控制装置用于检索由所述数据存储部存储的所述块
数据,将所述块数据存储到所述临时数据存储部中,并且从所述临时数据存储部检索所述
块数据;以及
临时数据控制装置,所述临时数据控制装置用于控制由所述临时数据存储部存储的所
述块数据的存储状态,
其中:
所述数据检索控制装置使得所述临时数据存储部基于从所述检索轮次信息存储部获
取的所述检索轮次信息来存储从所述数据存储部获取的所述块数据;以及
所述临时数据控制装置基于所述检索轮次信息来控制在所述临时数据存储部中的所
述块数据的所述存储状态。
12.根据权利要求11所述的计算机程序,其中,
基于所述检索轮次信息,通过删除由所述临时数据存储部存储的所述块数据,所述临
时数据控制装置控制在所述临时数据存储部中的所述块数据的所述存储状态。
13.根据权利要求11或者12所述的计算机程序,其中,
基于所述检索轮次信息,通过删除具有离目标块数据的轮次远的检索轮次的块数据,
所述临时数据控制装置控制在所述临时数据存储部中的所述块数据的所述存储状态,所述
目标块数据是待由所述数据检索控制装置检索的块数据。
14.一种信息处理方法,包括:
获取检索轮次信息,所述检索轮次信息是关于块数据的检索的轮次的信息;
使得临时存储设备基于所获取的检索轮次信息来存储从存储设备获取的所述块数据;
以及
基于所述检索轮次信息,来控制在所述临时存储设备中的所述块数据的存储状态。
15.根据权利要求14所述的信息处理方法,包括:
基于所述检索轮次信息,通过删除由所述临时数据存储设备存储的所述块数据,控制
在所述临时数据存储设备中的所述块数据的所述存储状态。
16.根据权利要求14或者15所述的信息处理方法,包括:
基于所述检索轮次信息,通过删除具有离目标块数据的轮次远的检索轮次的块数据,
控制在所述临时存储设备中的所述块数据的所述存储状态,所述目标块数据是待检索的块
数据。

?#24471;?#20070;

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

技术领域

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

背景技术

一种具有消除重复存储功能的存储设备?#36824;?#30693;为用于有效?#23454;?#22788;置大量数据的
技术。

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

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

进一步地,例如,在专利文献2中也描述了一种处置上述问题的技术。专利文献2描
述了一种存储设备,该存储设备具有数据划分装置、块检测装置和数据写入装置。根据专利
文献2,块检测装置检测共同?#21097;?#35813;共同?#26102;?#31034;在经划分的块数据当中写入目标数据的给定
?#27573;?#36827;行构成的多个连续块数据与已经顺序地存储在存储设备中的给定?#27573;?#20013;的多个块
数据之间的共同部分的比率。进一步地,数据写入设备根据由块检测装置检测到的共同率
来将经划分的块数据重新存储到存储设备中。根据专利文献2,这样的构成使得能够进行控
制以便仅在例如共同率小于给定阈值时将块数据重新写入存储设备。因此,根据专利文献
2,有可能?#31181;?#22359;数据在存储设备内的整个存储区域中的分散。因此,变得有可能?#31181;?#26816;索
性能的?#26723;汀?br />

参考文献

专利文献

专利文献1:WO2014-136183

专利文献2:JP 2013-541055

发明内容

技术问题

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

因此,仍然难以?#31181;?#22312;具有消除重复存储功能的存储设备中的检索性能的?#26723;汀?br />

因此,本发明的目的是提供一种存储设备,该存储设备可以解决难以?#31181;?#22312;具有
消除重复存储功能的存储设备中的检索性能的?#26723;?#30340;上述问题。

技术方案

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

数据存储部,该数据存储部存储经去重的块数据;

临时数据存储部,该临时数据存储部临时存储从数据存储部获取的块数据;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

有益效果

利用上述配置,本发明可以实现可以解决难以?#31181;?#26816;索性能的?#26723;?#38382;题的存储设
备。

附图?#24471;?br />

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

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

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

图4是用于描述由在图3中示出的?#25490;?#35774;备存储的数据的示意图;

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

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

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

图8是用于描述由在图3中示出的?#25351;?#31649;理部?#31181;?#34892;的数据检索过程的表达的示
意图;

图9是用于描述由在图3中示出的?#25351;?#31649;理部?#31181;?#34892;的该数据检索过程的表达的
示意图;

图10是示出了由在图3中示出的存储系?#25345;?#34892;的检索过程的操作的流程图;

图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中示出的?#25490;?#35774;备12存储的数
据的示意图。图5是用于描述由在图3中示出的缓存内存14存储的数据的示意图。图6是示出
了在图5中示出的块数据轮次信息141的配置的示例的示意图。图7是示出了在图5中示出的
数据信息142的配置的示例的示意图。图8和图9是用于描述由在图3中示出的?#25351;?#31649;理部分
13执行的数据检索过程的表达(appearance)的示意图。图10是示出了由在图3中示出的存
储系统1执行的检索过程的操作的流程图。

在本发明的第一示例性实施例中,将对具有去重功能并且通过有效率使用缓存内
存14来?#31181;?#26816;索性能的?#26723;?#30340;存储系统1进行描述。当在该示例性实施例中的存储系统1执
行?#25351;?#26102;,存储系统1通过使用指示块数据的检索顺序的元数据来控制在缓存内存14中的
块数据的存储状态,将在稍后对其进行描述。通过执行这样的控制,存储系统1可以在?#25351;?br />期间?#35272;?#20110;由缓存内存14存储的待检索的每个块数据的下一轮次来选择应当留在缓存内
存14中(从缓存内存14中删除)的块数据,将在稍后对其进行描述。因此,可以?#26723;?#22312;重用之
前删除由缓存内存14存储的块数据的风险和保持完全不必要的块数据被存储在缓存内存
14中的风险,并且可以?#31181;?#26816;索性能的?#26723;汀?br />

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

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

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

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

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

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

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

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

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

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

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

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

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

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

在该示例性实施例中的?#25490;?#35774;备12存储以上面的方式写入的块数据。换言之,磁
盘设备12根据需要以在?#25490;?#20013;向后添?#26377;?#30340;块数据的方式存储块数据。具体的,例如,参照
图4,为了对数据A1、A2和A3进行备份,以A1、A2和A3的顺序来将块数据写入?#25490;?#35774;备12。然后,
为了在上面的过程之后对数据A1、A2、B1和A3进行备份,在数据A1、A2和A3之后将新数据B1写入
?#25490;?#35774;备12。然后,为了在上面的过程之后进一步对数据A1、C1、B1、A3和C2进行备份,在数据
A1、A2、A3和B1之后将新数据C1和C2写入?#25490;?#35774;备12。

因此,?#25490;?#35774;备12存储通过被采用来进行去重备份的流行方法来写入的块数据。
可以在需要?#22791;?#21464;将块数据写入?#25490;?#35774;备12的条件、要写入的块数据的内容?#21462;?#20363;如,可以
将?#25490;?#35774;备12配置以使得检测共同率并且?#35272;?#20110;所检测到的共同率来写入块数据,该共同
?#26102;?#31034;配置写入划分的块数据的目标数据中的给定?#27573;?#30340;多个连续块数据与已经顺序地
存储在?#25490;?#35774;备12中的给定?#27573;?#30340;多个块数据之间的共同部分的比率。

?#25351;?#31649;理部分13基于从备份系统4接收到的流识别符来执行数据的?#25351;础?#25442;言之,
?#25351;?#31649;理部分13从备份系统4接收给出了对数据的?#25351;?#30340;指令的流识别符,从而复原由该
流识别符指示的文件。

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

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

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

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

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

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

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

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

数据信息142是示出了从?#25490;?#35774;备12获取的块数据的信息。例如,如在图7中示出
的,将数据信息142构造为标?#21152;成洌?#22312;该标?#21152;成?#20013;,内容地址(例如,如上所述,基于块数
据的数据内容来计算的散列值)是密钥并且数据是值。

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

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

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

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

例如,存储系统1具有元数据存储部11、盘存储部分12、?#25351;?#31649;理部分13、缓存内存
14和缓存内存控制部15,它们具有如上所述的配置。

随后,将参照图8和图9对在?#25351;?#31649;理部分13获取块数据时执行的过程的?#38468;?#36827;行
描述。

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

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

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

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

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

参照图9中的(1),发?#21482;?#23384;内存14未存储具有内容地址“d34mf”的块数据。因此,
例如,?#25351;?#31649;理部分13给出将在连续区域中写入的从具有内容地址“d34mf”的块数据开始
的四个块数据从?#25490;?#35774;备12加载到缓存内存14中的指示。因此,在图9中示出的情况下,连
同具有内容地址“d34mf”的块数据,检索具有内容地址“F5kd9”、“pwQ2e”和“zc5Tf”的块数
据。

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

之后,?#25351;?#31649;理部分13和缓存内存控制部15执行参照图8描述的过程,从而从缓存
内存14获取块数据并?#19968;?#26356;新块数据轮次信息141和数据信息142。

这是对在?#25351;?#31649;理部分13获取块数据时执行的示例的描述。接下来,参照图10,将
对在存储系统1?#25351;?#25968;据时的操作进行描述。

参照图10,存储系统1的?#25351;?#31649;理部分13接收给出从备份系统4?#25351;?#25968;据的指令的
流识别符(步骤S001)。

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

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

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

同时,在未将待获取的目标块数据存储在缓存内存14中的情况下(步骤S003:否),
例如,?#25351;?#31649;理部分13给出将四个连续块数据从?#25490;?#35774;备12加载到缓存内存14中的指令
(步骤S004)。

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

之后,执行上述的处理步骤S007。换言之,?#25351;?#31649;理部分13从缓存内存14获取目标
块数据,并?#19968;?#23384;内存控制部15更新缓存内存14(步骤S007)。同样,在由缓存内存14存储的
块数据的数目不大于阈值的情况下(步骤S005:否),以与上述方式相同的方式来执行处理
步骤S007。

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

因此,在该示例性实施例中的存储系统1具有元数据存储部11和缓存内存控制部
15。利用这样的配置,缓存内存控制部15可以通过使用基于由元数据存储部11存储的元数
据所生成的块数据轮次信息来执行对在缓存内存14中的块数据的存储状态的控制。换言
之,缓存内存控制部15可以基于块数据轮次信息来删除检索轮次离待由?#25351;?#31649;理部分13检
索的目标块数据的检索轮次远的块数据。因此,有可能?#26723;?#22312;重用之前删除由缓存内存14
存储的块数据的风险以及保持完全不必要的块数据被存储在缓存内存14中的风险。因此,
有可能?#26723;?#20174;?#25490;?#35774;备12检索重复的块数据的频?#21097;?#24182;且有可能?#31181;?#30001;在单个流中多次出
现的块数据所致使的检索性能的?#26723;汀?#25442;言之,有可能实现可以解决难以?#31181;?#26816;索性能的
?#26723;?#38382;题的存储系统1。

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

<第二示例性实施例>

接下来,在本发明的第二示例性实施例中,将对存储系统6进行描述,所述存储系
统6?#35272;?#20110;在写入目标数据中的多个连续块数据与已经被顺序地存储在?#25490;?#35774;备12中的多
个块数据之间的共同部分的比率来重写重复的块数据。

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

如在第一示例性实施例中一样,存储系统6具有通过使用内容地址来将数据存储
到?#25490;?#35774;备12中的功能。具体的,如稍后描述的,存储系统6通过划分和分布数据并且利用
内容地?#20998;?#23450;存储位置来存储数据。下面将参照图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实际存储到?#25490;?#35774;备12中的需要。

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

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

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

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

?#24065;?#19978;述方式将请求写入的数据写入存储系统6时,存在以下情况:将通过划分数
据获得的多个块数据分散并且存储在如上所述的?#25490;?#35774;备12中。在这种情况下,存在检索
性能?#26723;?#30340;担忧,但是在该示例性实施例中的存储系统6还具有以下功能以便解决这样的
问题。下面,将参照图14至图16来对该功能进行详?#35813;?#36848;。

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

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

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

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

因此,当连续块数据之间的共同?#24335;?#22823;时,可以说,在与写入请求有关的数据A的
目标块之后的其它块数据也被存储在具有与?#25490;?#35774;备12中的目标块相同内容的块数据之
后的预定?#27573;?#20013;的区域中。因此,数据写入部68对如上所述的目标块执行通常的存储过程。
之后,数据写入部68对下一目标块——?#20174;?#20889;入请求有关的数据A的块数据2执行如上所述
的相同过程。因此,在稍后检索与写入请求有关的数据A时,有可能通过检索已经存储的数
据B的连续块数据来有效?#23454;?#26816;索数据A。此外,因为还执行了对块数据的重复存储的消除,
所以有可能减小存储容量。

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

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

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

进一步地,如上所指出,数据写入部68并非始终重新地写入块数据,而是仅在满足
以下条件时重新写入块数据。例如,数据写入部68相对于在与写入请求有关的数据A当中
(例如,在与当前写入请求有关的一系列流数据当中)已经写入?#25490;?#35774;备12的数据的容量来
计算以重复的方式重新写入?#25490;?#35774;备12的块数据的容量的比?#21097;?#24182;且在该比?#23454;?#20110;或者小
于预定比率(例如,5%)时写入该块数据。因此,有可能限制重复的并且存储在?#25490;?#35774;备12
中的块数据的量。此外,通过限制重新写入?#25490;?#35774;备12的容量,有可能限制由于重写而导致
的写入速度的?#26723;汀?#20877;次写入块数据的条件可以是任何条件。例如,条件可以是:使得写入
的块数据的容量等于或者小于先前?#35272;?#20110;?#25490;?#35774;备12的容量所设定的容量。

进一步地,可以将数据写入部68配置为:当相同的块数据在与写入请求有关的一
系列流数据内出现时,仅将在用于写入?#25490;?#35774;备12的一系列流数据内最先出现的块数据作
为目标。

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

如在第一示例性实施例中描述的,根据该示例性实施例的存储系统6可以通过有
效?#23454;?#20351;用缓存内存14来限制检索性能的?#26723;汀?#22240;此,在如上所提到的情况下,认为可以通
过有效?#23454;?#20351;用缓存内存14而无需再次执行写入过程来限制检索性能的?#26723;汀?#22240;此,在相
同块数据出现在一系列流数据内的情况下,认为可以通过仅将首先出现在一系列块数据内
的块数据作为目标以用于写入?#25490;?#35774;备12,?#35789;?#29616;限制检索性能的?#26723;?#30340;有效率重写判
断。

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

因此,根据在该示例性实施例中的存储系统6,有可能在执行对重复存储的消除的
同时,限制块数据在?#25490;?#35774;备12内的整个存储区域中的分散。因此,在稍后检索数据时,有
可能限制?#28304;?#37327;?#25490;?#30340;扫描,并且有可能限制检索性能的?#26723;汀?#21478;一方面,为了限制检索性
能的?#26723;停?#20801;许对块数据的重复存储,但是有可能通过限制重复存储的容量来限制存储容
量的增加。

<第三示例性实施例>

在本发明的第三示例性实施例中,将对具有临时数据控制部的存储设备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中的风险。因此,可以?#31181;?#26816;索性能的?#26723;汀?br />

<第四示例性实施例>

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

<第1章引言>

<1.1动机>

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

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

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

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

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

<1.2问题陈述>

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

<1.2.1碎片化对?#25351;?#24102;宽的影响>

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

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

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

全局碎片化-由彼?#23435;?#36923;辑连接的相同块在备份中出现所导?#38534;?br />

在图21中呈?#33267;?#20855;有上述因素中的每一个的示意性成本,表现为?#25351;?#24102;宽?#26723;汀?br />在本文中,我将深入研究两个主要因素(如在进一步分析期间发现的):版本间碎片化和内
部流碎片化。

<1.2.2版本间碎片化>

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

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

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

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

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

<1.2.3内部流碎片化>

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

足以来?#24471;?#20869;部流碎片化问题的情况是,将具有某平均数目的内部重复块的单个
数据流备份到具有去重的系统。因为系统仅存储每个块的一个副本,所以,将不再按照这样
的方式来将通常连续的备份存储在?#25490;?#19978;(见图23)。这导致读取数据需要大量的?#25490;?#23547;
道,并且因?#35828;?#33268;非常低的读取性能(见图23中的备份的?#25351;?#36807;程方案)。

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

<1.3论文贡献>

考虑到所描述的场景,本文的目标在于对写入性能和去重有效性二者无?#22909;?#24433;响
的情况下避免?#25351;?#24615;能的?#26723;汀?#25442;言之,理想的去重解决方案应当在没有由任何种类的碎
片化致使的任何读取弊端的情况下,实?#25351;?#20889;入带宽——如当前通过在线方法来提供的和
高?#25351;?#24615;能。

本文的主要贡献是:

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

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

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

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

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

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

<1.4论文大纲>

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

<第2章备份和去重>

<2.1辅助存储系统>

<2.1.1要求>

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

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

备份系统要求[23]:

·在紧急情况下的快速数据?#25351;?br />

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

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

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

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

·按需求删除

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

<2.1.2历史>

尽管第一台通用计算机是在1946年建成的并且备份演进似乎相当短暂,但也是非
常剧烈的一次演进。第一个可用的穿孔卡可以存储少于100?#32440;?#30340;数据,而最新的设备可以
保持超过1TB的数据。在这样的短的时间?#25991;?#30340;巨大?#31245;?#31034;出?#23435;?#35753;每个用户得到最大限
度的计算机体验而?#24230;?#21040;开发技术中的工作量。

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

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

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

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

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

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

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

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

<2.2重复消除>

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

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

<2.2.1特性>

粒度

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

算法

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

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

应用点

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

应用时间

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

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

?#27573;?br />

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

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

<2.2.2去重率>

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

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

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

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

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

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

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

<2.2.3益处>

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

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

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

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

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

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

·可用原始容量的增倍

·易于仅复制唯一的数据

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

·允许用于备份的?#25490;?#25216;术、以及:

-在?#35813;?#38047;内随机存取

-快速紧?#34987;指?同时从多个?#25490;?

-多次流存取

-文件系统接口

-可配置的弹性等级

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

<2.2.4缺点和担忧>

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

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

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

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

<2.3当今市场>

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

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

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

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

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

<3.1?#25351;?#22312;备份系统中的角色>

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

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

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

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

<3.1.1备份程序>

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

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

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

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

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

预取

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

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

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

缓存

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

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

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

效率问题

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

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

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

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

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

一般而言,存在三种碎片化问题,每个碎片化问题由数据去重的不同方面导致,其
中,对最终?#25351;?#24102;宽有完全单独的影响(见图33)。可以在以下章节中找到对每个区域的详
?#35813;?#36848;和分析。

<1.2.3内部流碎片化>

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

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

注意,块i'6和i'129不导致附加?#25490;?#23384;取,即使它们不在主序列中(从i'279到i'
304)。这是由于以下事实:由于先前读取的块i'5和i'128不需要额外的I/O,因此在进行读
取时,这些块将存在于缓存内存中。此外,人们可以注意到名为i'5的两个块,而只有第一个
被标记为导致?#25490;?#23384;取。其简单地假设因为仅先于27个块读取块i'5,所以在?#25351;?#20854;第二个
副本期间,该块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),这意味着具有去重的系统?#25351;?#30456;同备份数
据的时间多一半。注意,我?#19988;?#32463;假设了适度大的缓存大小,否则我们可能需要重新考虑添
加额外的I/O以读取第二个i'5块(逻辑偏移431),因为可能已经同时从缓存中逐出了该第
二个i'5块(读取偏移404与431之间)。

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

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

<1.2.2版本间碎片化>

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

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

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

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

将以这样的方式?#35789;?#29616;碎片化称为版本间碎片化。此处独特的事实是,当人们开
始使用该系统时,不存在这样的类型的碎片化,并且这种碎片化在以下备份期间以对于每
个数据集和使用模式非常唯一的速?#35797;?#21152;。因为该过程在共同备份周期期间是不可见的,
所以当?#25351;?#24517;要时,通常会出现该过程,这可以揭开比预期的?#25351;?#24102;宽?#22270;副?#30340;?#25351;?#24102;宽
的问题。在?#25351;?#26159;紧急问题的情况下,这样的发现可能具有非常昂贵的后果。

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

<3.2.3全局碎片化>

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

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

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

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

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

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

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

<3.2.4可扩缩性问题>

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

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

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

<3.3问题?#32771;?gt;

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

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

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

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

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

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

<3.3.2时间上的碎片化>

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

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

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

<3.3.3缓存大小对?#25351;?#26102;间的影响>

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

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

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

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

<3.4用于在?#25351;?#26399;间减少碎片化的消极影响的选择>

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

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

一种令人关注的解决方案将是使用缩减去重?#20174;Χ运?#29255;化。在该方法中,每当在
备份期间,一些当前写入的块在?#25490;?#19978;相距很远时,无论现有的副本如何,都可以将其简单
地存储在?#25490;?#19978;。不幸的是,如解决方案中的一个示出[48],该路径导致?#31995;?#30340;重复?#21097;?#29305;
别是当朝着合理的?#25351;?#32467;果移动时。令人关注的权衡将?#19988;?#36825;种方式但使用将节省完全去
重的其它技术?#20174;?#23545;全局碎片化(因为它通常是由小数目的重复导致的),以解决版本间和
内部流碎片化。

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

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

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

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

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

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

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

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

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

·提供接近利用所采用的B'el'ady的缓存?#35789;?#29616;的?#25351;?#24102;宽的?#25351;?#24102;宽(并且当
然显著地高于LRU),

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

·如果?#25351;?#31639;法有任何修改,则仅强制执行少量,

·不需要?#25351;?#31639;法以外的任何改变,

·不需要很多的附加资源,诸如?#25490;?#24102;宽、转轴和处理能力。

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

<4.2想法>

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

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

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

<4.3系统支持>

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

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

·具有单个流识别符的整个备份?#25351;矗?#34987;递送?#26009;?#32479;的单个识别符应当足以读取
整个备份;

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

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

<4.4算法?#38468;?gt;

<4.4.1系统?#25351;?#31639;法>

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

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

<4.4.2?#25490;袒指?#36807;程>

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

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

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

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

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

[数学公式1]


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

缓存的块位置

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

逐出策略

图45和图46示出了在两种情况下的块?#25351;?#21644;缓存逐出策略的示例。第一个示例:
当在缓存中找到块时,以及第二个示例:当必须从?#25490;袒指?#22359;时。在前一种情况下,所执行
的唯一操作是在缓存和智囊结构中实际更新所?#25351;?#30340;块。后一种情况要更复杂,并?#19968;?#21253;
括缓存逐出过程。一般而言,缓存逐出过程由以下步骤组成:

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

·更新缓存优先级队列,使通过下一次出现的具有?#25351;?#30340;块的段的方式来对块进
?#20449;?#24207;。

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

·继续按照与通过缓存执行?#25351;?#26102;的方式相同的方式来更新结构(4.5)。

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

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

<4.4.3内存需求>

因为按照与具有LRU算法的缓存非常类似的方式来构建在利用先期知识的算法中
的缓存本身,所以其内存需求不发生改变。然而,利用其先期知识的智囊将需要单独的和专
用的内存。另一需求可以是在其作为先期知识被接收之后但在其实?#26102;?#29992;于?#25351;?#25968;据之前
等待被?#25351;?#30340;所有块地址的附加列表。因为先期知识大小可以覆?#20999;?#22810;千兆?#32440;冢?#25152;以在
地址被用于?#25351;?#25968;据之前,可能花费许多秒(我假设递送?#35828;?#22336;以便在尽可能快地执行恢
复的同时填充先期知识),这意味着其需要专用内存。在第4.4.4章节中详?#35813;?#36848;的替选方
法可以是不?#21152;?#38468;加内存,但是将元数据?#25351;?#20004;次:一次是用于先期知识,以及第二次是用
于?#25351;?#26412;身。无论使用哪种解决方案,?#21152;?#24403;将适当的内存大小包括在为?#25351;?#32531;存所指派
的总内存中。

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

<4.4.4?#33268;?gt;

替选解决方案

重要的观察是,仅保留将来要读取的数据的地址的列表已经消耗了所需要的附加
内存的三?#31181;?#20108;(每个块保留33?#32440;?#20013;的20?#32440;?。下面呈?#33267;?#29992;以最小化这种影响的值得
考虑的一个想法。

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

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

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

因为将利用提出的算法来大大的修?#33041;?#25968;据?#25351;?#30340;模式,所以出?#33267;?#20854;对?#25351;?#24615;
能的影响问题。有关该主题的?#33268;?#24635;体上是困难的,因为它需要给定系统和其元数据?#25351;?br />过程的详细知识。?#20197;?#30340;是,因为元数据通常只是待?#25351;?#30340;所有数据中的一小部分
(0.256%,其中每个8KB为20?#32440;?,所以即使再次全部读取它?#19988;?#19981;应当产生大量额外的
工作。而且,当考虑到具有每个块超过100?#32440;?#30340;高元数据开销的系统[69]时,在相同场景
中的总?#25351;?#24102;宽劣化将仍然低于1.5%,该劣化应当几乎不被注意。

<4.5权衡>

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

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

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

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

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

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

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

该问题需要对去重系统的其它重要度量没有?#22909;?#24433;响的解决方案。这样的解决方
案应当:

·消除由最新备份的版本间碎片化所导致的?#25351;?#24102;宽减少

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

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

·不需要很多的附加资源,诸如?#25490;?#24102;宽、转轴和处理能力。

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

<5.2想法>

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

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

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

<5.3系统支持>

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

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

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

·快速确定?#25490;?#30456;邻块:给定两个块,系统应当能够快速确定它们在?#25490;?#19978;是否
彼此靠近。当确认在系统中的块存在的每个查询返回该块在?#25490;?#19978;的位置时,可以实现这
一点。

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

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

<5.4算法?#38468;?gt;

<5.4.1块上下文>

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

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

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

<5.4.2保持上下文类似>

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

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

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

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

<5.4.3作出重写决定>

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

重写效用

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

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

最小重写效用

最小效用是CBR算法的恒定参数以便避免重写,这将仅稍微地提高?#25351;?#24615;能。我已
经将最小重写效用设置为70%。该值可能看起来很高,但是如在下面的分析中呈现的,?#31995;?br />的最小效用不是很有用。

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

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

当前效用阈值

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

为?#31169;?#31435;最佳5%,在不考虑算法采取的实?#35782;?#20316;的情况下计算重写到目前为止
所看到的每个复本的效用。在算法的每个循环中,当前重写效用阈?#24403;?#35774;置为重写最佳5%
块中最坏的块的效用。这样的选择大致意味着如果已经将该值用作从备份的开始直到当前
点的每个判定块的当前效用阈值,并且没有对重写的块的数目的限制,则算法将重写所有
的最佳5%块。

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

重写决定

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

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

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

<5.4.4实现?#38468;?gt;

计算上下文交集

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

调整重写效用阈值

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

?#38405;?#37096;流复本进行过滤

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

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

在这样的情况下,针对每个1GB的预期数据,我们需要大约240KB的内存以便不超
过流的最后?#32440;?#30340;0.1%误报率(每密钥15位、128×1024个密钥、7个散列函数)。这样的数
目是可接受的,因为正如具有最多5%的块要重写,通常它们中的少于4个(?#33268;?#20272;计)将被
错误地假设为内部复本。因为1GB的数据需要至少500次I/O,所以对?#25351;?#24102;宽的?#22909;?#24433;响将
通常远小于1%。

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

在写入期间读取模拟

所呈现的CBR算法在通过重写小数目的块来确保更多的连续?#25490;?#23384;取时表?#33267;?br />好。然而,最后,重要的是在读取流时实现的?#25351;?#24615;能。将该结果保持在相同水平,连同进一
步减少重写的块的数目一起,将有助于?#26723;?#22312;每个备份期间的所支付的成本。

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

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

后台操作

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

对读取操作的修改

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

<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?#33268;?gt;

优化在线算法

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

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

?#20197;?#30340;是,在所有经测试的数据集中,以上问题处于最?#22270;?#21035;还因为所重写的块
的数目总是低于5%的水平。因此,即使利用在线算法,最终结果也非常接近于利用无版本
间碎片化所实现的最终结果。

离线CBR

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

<5.5权衡>

流上下文大小

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

注意,将仅针对已经具有显著时延的非重复块引入来自以上示例的?#26144;佟?br />

重写数目

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

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

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

<6.1实验方法>

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

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

<6.1.1备份系统模型>

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

写入模拟

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

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

?#25351;?#27169;拟

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

在所有实验中,使用固定大小的预取,所以,我们可以假设在?#25351;?#26399;间,读取带宽
与数据I/O操作的数目成反?#21462;?#34429;然确实存在性能受其它因素影响的系统,但是我认为将实
现的带宽与固定大小的I/O的数目相关使我们能够专注于碎片化问题的核?#27169;?#24182;且忽略次
要因素,诸如网络和CPU速?#21462;?br />

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

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

?#28304;排?#19978;下文/预取大小的选择

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

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

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

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

<6.1.2忽略的因素>

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

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

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

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

<6.1.3数据集描述>

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

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

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

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

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

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

·?#22987;?在软件公司(tar)中的35个用户的邮箱

<6.1.4测试场景>

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

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

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

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

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

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

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

<6.2.1满足需求>

性能结果

在第4章中呈现的具有有限的先期知识的缓存在碎片化的和未碎片化的数据(包
括离线去重)二者的每个备份(包括最新备份)的?#25351;?#26399;间优化内存使用时确?#21040;?#34892;得很
好,从而确保了平均?#25351;?#24102;宽增加了62%到88%之间(见图52)。

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

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

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

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

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

可调谐性

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

代码修改和去重

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

<6.2.2设置先期知识大小>

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

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

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

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

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

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

当针对具有不同的先期知识大小的缓存内存使用效?#35797;?#27425;比较图53与图54时,可
以观察到一个受关注的事实。虽然针对前者(具有版本间碎片化),8GB的先期知识即使对于
1GB缓存来说都足以保持在具有无限的先期知识的算法的最大8%内(平均2.48%),但是由
于随着每个I/O?#25351;?#26356;多值得保留的数据,因?#23435;此?#29255;化的选项具有更高的需求。在这种情
况下,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]中使用的预取大小相似,表
明可以将其视为最常见的预取大小。虽然如此,但是其表明了使用利用先期知识的缓存算
法显著修改了这些假设。为了将针对预取大小在?#25351;?#24102;宽方面的差异可视化,我已经利用
普通企业?#25490;?#29305;性执行了模拟[71](保持数据传输速率为175MB/s,读取存取时间为
12.67ms)。在图56中示出的结果表明:在每个条件下(碎片化的和未碎片化的),并且通过使
用不同的?#25351;?#31639;法,每个备份具有自己的最佳预取大小,该最佳预取大小对于彼此可以大
不相同。一个清楚的观察是:当与碎片化的数据相比较时,这样的最佳预取针对没有碎片化
的数据始终更大,并且当与LRU相比时,该最佳预取对于先期知识算法始终更大。因此,转换
到更大的预取通过更小数目的I/O改善了?#25351;?#24102;宽,该更小数目的I/O限制了非生产性的寻
道。由于使用了先期知识算法,预取大小可以比利用LRU的情况大2到6倍,因此,针?#36816;?#29255;化
的数据,提供了水平为11%-117%(平均为68.47%)的最大?#25351;?#24102;宽增加,并且对于未碎片
化的数据,提供了水平为27%-252%(平均为120.24%)的最大?#25351;?#24102;宽增加。当与利用先
期知识和2MB的预取实现的结果相比时,扩展预取大小对于碎片化的数据可以产生0%-
48%(平均为23.89%)的附加增益,并且对于未碎片化的数据可以产生3%-92%(平均为
53.90%)的附加增益。

<6.3CBR有效性的评估>

<6.3.1满足要求>

性能要求

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

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

使用的额外的空间和资源

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

可调谐性

通过设置待重写的块的百分比,?#37096;?#23481;易地调谐所提出的算法。百分比越高,?#25351;?br />性能越好,代价是写入性能下降越大,临时存储重写的块的旧副本需要的?#25490;?#31354;间越大。

<6.3.2重写的成本>

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

结果,复本的带宽?#30830;?#22797;本高3倍。基于该数字,我已经使用了减速因子4来重写块
(针对标准复本写入/验证使用1,针?#36828;?#22806;写入使用3),对比对该块进行去重。例如,重写
5%的块导致从5.17%上至15%的减速。由于所有重写的块都是复本,所以实?#22987;?#36895;取决于
复本在原始流中的百分?#21462;?#30334;分比越高减速越高,并且,当流中的所有块都是复本时,实
?#33267;?5%的减速。

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

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

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

<6.3.3设置重写限制>

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

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

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

经重写的重写本

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

由于重写的块的总数目仍然非常小,我已经决定保持该算法的该版本从而确保更
好的?#25351;?#24102;宽。

<6.3.4压缩的效果>

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

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

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

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

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

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

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

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

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

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

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

<6.5可扩缩性>

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

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

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

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

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

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

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

<第7章相关工作>

<7.1与离线去重的比较>

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

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

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

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

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

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

<7.2碎片化测量>

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

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

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

我提出的指标“%的?#25351;?#24102;宽无复本”与以上指标实际上非常相?#39057;?#20855;有一些修
改(见图68中的对比)。首先,其名字清楚地表明了它的含义,使其使用起来非常直观。其次,
其不以任何方式限制结果,即使是在其比在不具有去重的系统中更好的情况下,也能够非
常良好地预测输出性能。再次,其高度独立于写入算法并且不?#35272;?#20110;所使用的容器大小,这
可以有助于使其可用在较大?#27573;?#30340;系统以便利用不同的预取?#21040;?#34892;试验。当然,?#37096;?#20197;容
易地对其进行限制以?#20174;?#19982;固定容器大小的指标实际上相同的行为。最后但并非最不重要
的因素是模拟所使用的缓存逐出策略。我的实验示出,毫无疑问该因素在测?#20811;?#29255;化时是
一种极其重要的因素,并且?#28304;?#21040;的结果可以具有非常大的影响。

<7.3去碎片化算法>

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

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

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

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

<7.4缓存>

前向组装区域(Forward assembly area)[48]是除了容器限顶之外的由
Lillibridge等人提出的第二种技术,旨在通过在?#25351;?#24320;始时使用备份的配方来帮助实现
更好的缓存内存使用(与先期知识相似)。在最简单的情况下,作者利用为读取的?#21046;?#25152;分
配的必要的内存来将完整备份?#25351;次狹?#32440;?#30340;?#21046;?#25152;分配的内存被称为前向组装区域。为
了?#25351;?#21333;个M?#32440;?#30340;?#21046;?#20182;们首先将配方的对应部分读取到内存缓冲区中,并且确定需要
哪些组块来填充所要求的?#32440;詵段А?#27599;次对组装区域中的最早没有填充的组块点进行局部
化时,在填充组件中需要组块形成该容器的所有部分的同时?#25351;?#30456;对应的容器。在完成该
过程之后,可以向用户返回数据,并且可以清空该组件区域以读取下一个M?#32440;?#30340;?#21046;?br />

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

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

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

<7.5其它相关的工作>

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

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

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

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

<第8章结论>

<8.1概要>

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

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

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

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

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

我的踪迹驱动式模拟已经表明,重写一些所选择的块(平均为1.58%)略微(1-
9%)?#26723;?#20102;最大写入性能,但是实际上,消除了最新的备份的?#25351;此?#24230;?#26723;停?#20174;利用LRU缓
存的最大带宽的12-51%至最多7%(平均为2.6%)。

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

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

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

<8.2将来的工作>

<8.2.1完善在?#25351;?#26399;间的内存划分>

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

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

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

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

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

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

<8.2.3变量大小预取>

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

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

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

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

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

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

·在写入期间利用先期知识模拟缓存算法(实际上与?#25351;?#25152;用的方法相同或者相
似);

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

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

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

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

<8.2.6全局碎片化>

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

<附录>

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

(附录1)

一种存储设备,包括:

数据存储部,所述数据存储部存储经去重的块数据;

临时数据存储部,所述临时数据存储部临时存储从所述数据存储部获取的块数
据;

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

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

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

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

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

(附录2)

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

(附录3)

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

(附录4)

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

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

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

(附录5)

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

(附录6)

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

(附录7)

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

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

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

(附录8)

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

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

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

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

所述块检测部检测共同?#21097;?#25152;述共同?#26102;?#31034;在通过所述数据划分部作出的划分而
获得的所述块数据当中的所述写入目标数据?#20449;?#32622;预定?#27573;?#30340;多个连续块数据与已经按
顺序被存储在所述数据存储部中的预定?#27573;?#20869;的多个块数据之间的共同部分的比?#21097;?#20197;及

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

(附录9)

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

(附录10)

根据附录9所述的存储设备,其中,所述数据写入部使用布隆过滤器来判断所述块
数据是否?#29366;?#20986;现在所述写入目标数据中。

(附录10-1)

根据附录8至10中任一项所述的存储设备,其中,所述数据写入部被设置以使得,
在所述写入目标数据当中重写的块数据的量相对于已经被存储在所述数据存储部中的数
据的量的比?#26102;?#24471;等于或者小于预设比?#21097;?#25152;述重写的块数据?#19988;?#25454;所述块检测部所检测
到的所述共同率来被重新存储到所述数据存储部中的块数据。

(附录11)

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

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

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

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

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

(附录12)

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

(附录13)

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

(附录14)

一种信息处理方法,所述方法包括:

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

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

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

(附录15)

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

(附录16)

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

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

虽然上面已经参照示例性实施例来对本发明进行了描述,但是本发明不限于上面
描述的示例性实施例。在本发明的?#27573;?#20869;,可以按照本领域的技术人员可以理解的各种方
式来改变和修改本发明的配置和?#38468;凇?br />

附图标记描述

1,6 存储系统

11 元数据存储部

12 ?#25490;?#35774;备

13 ?#25351;?#31649;理部分

14 缓存内存

141 块数据轮次信息

142 数据信息

15 缓存内存控制部

66 数据划分部

67 块检测部分

68 数据写入部

2 加速器节点

3 存储节点

4 备份系统

5 备份目标设备

70 数据集

71 划分数据

72 冗余数据

8 存储设备

81 数据存储部

82 临时数据存储部

83 数据检索控制部

84 检索轮次信息存储部

85 临时数据控制部

关于本文
本文标题:存储设备、程序和信息处理方法.pdf
链接地址:http://www.pqiex.tw/p-6091799.html
关于我们 - 网站声明 - 网?#38236;?#22270; - 资源地图 - 友情链接 - 网站客服 - 联系我们

[email protected] 2017-2018 zhuanlichaxun.net网站版权所有
经营许可证编号:粤ICP备17046363号-1 
 


收起
展开
平码五不中公式规律 码报纸 云南快乐10分走势图50 去哪里看日本排球比分 850游戏通比牛牛怎么样 网文网站怎么赚钱 七彩娱乐苹果 快乐扑克3同化最大遗漏 梦幻西游计算器 羽毛球比赛 天津快乐十分最新期号