CN103765393A - 存储系统 - Google Patents
存储系统 Download PDFInfo
- Publication number
- CN103765393A CN103765393A CN201280043434.9A CN201280043434A CN103765393A CN 103765393 A CN103765393 A CN 103765393A CN 201280043434 A CN201280043434 A CN 201280043434A CN 103765393 A CN103765393 A CN 103765393A
- Authority
- CN
- China
- Prior art keywords
- data
- lastest imformation
- memory device
- snapshot
- value
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
- G06F3/0601—Interfaces specially adapted for storage systems
- G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
- G06F3/0638—Organizing or formatting or addressing of data
- G06F3/064—Management of blocks
- G06F3/0641—De-duplication techniques
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/10—File systems; File servers
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/10—File systems; File servers
- G06F16/17—Details of further file system functions
- G06F16/174—Redundancy elimination performed by the file system
- G06F16/1748—De-duplication implemented within the file system, e.g. based on file segments
- G06F16/1752—De-duplication implemented within the file system, e.g. based on file segments based on file chunks
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/10—File systems; File servers
- G06F16/18—File system types
- G06F16/1873—Versioning file systems, temporal file systems, e.g. file system supporting different historic versions of files
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
- G06F3/0601—Interfaces specially adapted for storage systems
- G06F3/0602—Interfaces specially adapted for storage systems specifically adapted to achieve a particular effect
- G06F3/0614—Improving the reliability of storage systems
- G06F3/0619—Improving the reliability of storage systems in relation to data integrity, e.g. data losses, bit errors
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
- G06F3/0601—Interfaces specially adapted for storage systems
- G06F3/0668—Interfaces specially adapted for storage systems adopting a particular infrastructure
- G06F3/067—Distributed or networked storage systems, e.g. storage area networks [SAN], network attached storage [NAS]
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/10—File systems; File servers
- G06F16/11—File system administration, e.g. details of archiving or snapshots
- G06F16/128—Details of file system snapshots on the file-level, e.g. snapshot creation, administration, deletion
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/10—File systems; File servers
- G06F16/14—Details of searching files based on file metadata
- G06F16/148—File search processing
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Data Mining & Analysis (AREA)
- Databases & Information Systems (AREA)
- Human Computer Interaction (AREA)
- Computer Security & Cryptography (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
本发明的一种存储系统包括:数据写入装置,用于向存储设备中存储配置存储数据的实际数据,以及对于存储数据的内容的每次更新,新存储实际数据;以及数据指定装置,用于指定在存储设备中存储的相同存储数据之中的最新存储数据。数据写入装置被配置用于与对于每次更新其值增加1的更新信息关联地存储配置存储数据的实际数据。数据指定装置被配置用于按照i(i代表0或者更大的整数)的值的增加顺序检查其值为2i的更新信息是否存在于存储设备中,以及在存在的更新信息存在的为2i的最大值与2i+1之间的值之中指定对应的更新信息的最大值。
Description
技术领域
本发明涉及一种存储系统,更具体地涉及一种消除相同内容的数据的重复存储的存储系统。
背景技术
近年来,随着计算机的发展和普及各种信息被数字化。作为用于存储这样的数字数据的设备,存在存储设备,比如磁带和磁盘。由于应当被存储的数据量与日俱增并且达到庞大数量,所以需要海量存储系统。另外,也需要可靠性以及减少为存储设备花费的成本。此外,也需要稍后可以容易地取回数据。作为结果,期待一种可以自动实现增加存储容量和性能、消除重复存储以减少存储成本并且具有高冗余性的的存储系统。
在这样的境况之下,近年来,如在PTL1中所示,已经开发了一种内容可寻址存储系统。这一内容可寻址存储系统向多个存储设备中分布和存储数据,并且通过根据数据的内容指定的唯一内容地址指定其中存储数据的存储位置。具体而言,内容可寻址存储系统将预定数据划分成多个片段并且添加作为冗余数据的片段,并且然后分别向多个存储设备中存储这些片段。
稍后,有可能指明内容地址以取回数据(即,在由内容地址指定的存储位置中存储的片段)并且在被从片段划分之前恢复预定数据。
另外,使用数据的如下哈希值作为内容地址,生成该哈希值以便取决于数据的内容而唯一。因此,在重复数据的情况下,有可能引用在相同存储位置中的数据并且获取相同内容的数据。因而,不必分离地存储重复数据,并且有可能消除重复记录并且减少数据容量。
引用列表
专利文献
PLT1:日本未审专利申请公开号2005-235171
发明内容
技术问题
在以上描述的内容可寻址存储系统中,在存储的数据的内容被改变时,向存储设备中新写入在改变之后的数据,并且生成与新写入的数据的内容对应的内容地址。通过设置以便用这一内容地址引用新写入的数据的存储位置以及在另一方面以便不引用用于在改变之前的数据的内容地址来完成存储改变的数据的过程。
在如以上描述的那样访问已经被改变了的数据时,显然有必要访问最新数据。因此,有必要指定在存储设备中存储的最新数据。在改变之前的数据保持被存储于存储设备中并且包括以后不会被使用的数据。然后,将不会被使用的数据的增加造成存储容量的浪费。因而,需要从存储设备删除将不会被使用的数据,并且也在这一情况下,有必要指定最新数据。
然而,在频繁更新的数据的情况下,在改变之前的旧数据达到庞大数量,并且可能需要时间来执行指定最新数据的过程。然后,出现写入过程和读取过程可能延迟的问题。具体而言,多个上层主机和应用相互独立地执行写入的数据的管理并且控制数据的写入和读取,难以管理最新数据,并且有花费时间来指定的问题。
因而,本发明的目的是提供一种能够改进花费时间来指定最新数据的存储系统。
对问题的解决方案
本发明的一个示例性实施例的一种存储系统包括:
数据写入装置,用于向存储设备中存储配置待写入的存储数据的实际数据,并且每当存储数据的内容被更新时向存储设备中新存储配置更新的存储数据的实际数据;以及
数据指定装置,用于指定在存储设备中存储的相同存储数据之中的最新存储数据,其中:
数据写入装置被配置用于与每当存储数据被更新时其值增加1的更新信息关联地向存储设备中存储配置存储数据的实际数据;并且
数据指定装置被配置用于按照i(i代表等于或者大于0的整数)的值的增加顺序检查其值为2i的更新信息是否存在于存储设备中,从存在的更新信息存在的2i的最大值与2i+1的值之间的值之中指定对应的更新信息的最大值,并且指定由与更新信息的最大值关联的实际数据配置的存储是数据作为最新存储数据。
另外,本发明的另一示例性实施例的程序是一种包括用于使信息处理设备实现以下装置的指令的程序:
数据写入装置,用于向存储设备中存储配置待写入的存储数据的实际数据,并且每当存储数据的内容被更新时向存储设备中新存储配置更新的存储数据的实际数据;以及
数据指定装置,用于指定在存储设备中存储的相同存储数据之中的最新存储数据,其中:
数据写入装置被配置用于与每当存储数据被更新时其值增加1的更新信息关联地向存储设备中存储配置存储数据的实际数据;并且
数据指定装置被配置用于按照i(i代表等于或者大于0的整数)的值的增加顺序检查其值为2i的更新信息是否存在于存储设备中,从存在的更新信息存在的2i的最大值与2i+1的值之间的值之中指定对应的更新信息的最大值,并且指定由与更新信息的最大值关联的实际数据配置的存储是数据作为最新存储数据。
另外,本发明的另一示例性实施例的一种信息处理方法包括:
向存储设备中存储配置待写入的存储数据的实际数据,并且每当存储数据的内容被更新时向存储设备中新存储配置更新的存储数据的实际数据并且写入数据,并且这时与每当存储数据被更新时其值增加1的更新信息关联地向存储设备中存储配置存储数据的实际数据;并且
在指定在存储设备中存储的相同存储数据之中的最新存储数据时,按照i(i代表等于或者大于0的整数)的值的增加顺序检查其值为2i的更新信息是否存在于存储设备中,从存在的更新信息存在的2i的最大值与2i+1的值之间的值之中指定对应的更新信息的最大值,并且指定由与更新信息的最大值关联的实际数据配置的存储是数据作为最新存储数据。
本发明的有利效果
本发明被因此配置,并且因此可以提供一种能够缩短用于指定最新数据的过程的时间的存储系统。
附图说明
图1是示出整个系统的配置的框图,该系统包括根据本发明的第一示例性实施例的存储系统;
图2是示出根据本发明的第一示例性实施例的存储系统的配置的概况的框图;
图3是示出根据本发明的第一示例性实施例的存储系统的配置的功能框图;
图4(a)、图4(b)和图4(c)是用于说明在图3中公开的存储系统中的数据写入过程的方面的说明视图;
图5是用于说明在图3中公开的存储系统中的数据写入过程的方面的说明视图;
图6(a)和图6(b)是用于说明在图3中公开的存储系统中的数据搜索过程的方面的说明视图;
图7(a)和图7(b)是用于说明在图3中公开的存储系统中的数据搜索过程的方面的说明视图;
图8(a)和图8(b)是用于说明在图3中公开的存储系统中的数据搜索过程的方面的说明视图;
图9是用于说明在图3中公开的存储系统中的数据搜索过程的方面的说明视图;
图10是用于说明在图3中公开的存储系统中的数据搜索过程的方面的说明视图;
图11是用于说明在图3中公开的存储系统中的数据搜索过程的方面的说明视图;
图12是在本发明的第二示例性实施例中说明的报告中引用的视图;
图13是在本发明的第二示例性实施例中说明的报告中引用的视图;
图14是在本发明的第二示例性实施例中说明的报告中引用的视图;
图15是在本发明的第二示例性实施例中说明的报告中引用的视图;
图16a是在本发明的第二示例性实施例中说明的报告中引用的视图;
图16b是在本发明的第二示例性实施例中说明的报告中引用的视图;
图16c是在本发明的第二示例性实施例中说明的报告中引用的视图;
图16d是在本发明的第二示例性实施例中说明的报告中引用的视图;
图17是在本发明的第二示例性实施例中说明的报告中引用的视图;
图18是在本发明的第二示例性实施例中说明的报告中引用的视图;
图19a是在本发明的第二示例性实施例中说明的报告中引用的视图;
图19b是在本发明的第二示例性实施例中说明的报告中引用的视图;
图20a是在本发明的第二示例性实施例中说明的报告中引用的视图;
图20b是在本发明的第二示例性实施例中说明的报告中引用的视图;
图20c是在本发明的第二示例性实施例中说明的报告中引用的视图;
图21a是在本发明的第二示例性实施例中说明的报告中引用的视图;
图21b是在本发明的第二示例性实施例中说明的报告中引用的视图;
图22是在本发明的第二示例性实施例中说明的报告中引用的视图;
图23是在本发明的第二示例性实施例中说明的报告中引用的视图;
图24是在本发明的第二示例性实施例中说明的报告中引用的视图;
图25是在本发明的第二示例性实施例中说明的报告中引用的视图;
图26是在本发明的第二示例性实施例中说明的报告中引用的视图;
图27是在本发明的第二示例性实施例中说明的报告中引用的视图;
图28是在本发明的第二示例性实施例中说明的报告中引用的视图;
图29是在本发明的第二示例性实施例中说明的报告中引用的视图;
图30是在本发明的第二示例性实施例中说明的报告中引用的视图;并且
图31是示出在本发明的补充备注1中的存储系统的配置的框图。
具体实施方式
<第一示例性实施例>
将参照图1至图11描述本发明的第一示例性实施例。图1是示出整个系统的配置的框图。图2是示出存储系统的概况的框图,并且图3是示出存储系统的配置的功能框图。图4和图5是用于说明在存储系统中的数据写入过程的说明视图。图6至图11是用于说明在存储系统中的数据搜索过程的方面的说明视图。
这一示例性实施例示出在稍后描述的补充备注中公开的存储系统等的具体示例。以下将假设通过连接多个服务器计算机配置存储系统来进行描述。然而,在本发明中的存储系统不限于由多个计算机配置并且可以由一个计算机配置。
如图1中所示,根据本发明的存储系统1经由网络N连接到控制备份过程的备份系统4。备份系统4获取在经由网络N连接的备份目标设备5中存储的备份目标数据(待写入的数据),并且请求存储系统1存储数据。因而,存储系统1存储请求存储的备份目标数据作为备份。
如图2中所示,在这一示例性实施例中的存储系统1运用其中连接多个服务计算机的配置。具体而言,存储系统1包括加速器节点2和存储节点3,加速器节点2是控制存储系统1中的存储再现操作的服务器计算机,存储节点3是配备有用于存储数据的存储设备的服务器计算机。加速器节点2的数目和存储节点3的数目不限于图2中所示的数目,并且可以通过连接更多节点2和更多节点3来配置系统。
在这一示例性实施例中的加速器节点2配备有各自独立执行数据记录和再现过程的多个应用。也就是说,一个应用无论另一应用的操作如何都操作取回在存储节点3中存储的数据的过程以及改变和写入取回的数据的更新过程。
另外,在这一示例性实施例中的存储系统1是内容可寻址存储系统,该内容可寻址存储系统划分数据并且使数据冗余以向多个存储设备中分布和存储数据,并且通过根据存储的数据的内容设置的唯一内容地址指定其中存储数据的存储位置。稍后将详细描述这一内容可寻址存储系统。
以下,假设存储系统1是一个系统,将描述存储系统1的配置和功能。也就是说,可以在加速器节点2或者存储节点3中包括以下描述的存储系统1的配置和功能。存储系统1未必限于如图2中所示的配备有加速器节点2和存储节点3并且可以具有任何配置。例如,存储系统1可以由一个计算机配置。此外,存储系统1不限于内容可寻址存储系统并且只要它具有去重复功能就可以是任何存储系统。
图3示出在这一示例性实施例中的存储系统1的配置。如这一附图中所示,存储系统1由服务器计算机配置并且包括上述应用30和存储设备20。另外,存储系统1包括通过向配置存储系统1的计算机中安装程序来构造的数据写入部分11、数据取回部分12、数据指定部分13和数据删除部分14。然后,存储系统1响应于来自应用30的请求对存储设备20执行包括数据的更新的写入过程和取回过程。
将详细描述数据写入部分11的数据写入过程。例如,在从应用30接受对于写入预定数据(例如,具有预定容量的一个文件)的请求时,数据写入部分11首先基于内容可寻址存储系统的特性将文件划分成多个块B1,这些块是多个预定容量的实际数据。然后,数据写入部分11如图4(a)中所示向在存储系统1中的存储器中暂时存储块B1。在存储器中的大小超过某个大小时,如图4(b)中所示向在存储设备20中的预定区域中写入在存储器中的块B1。然后,由于响应于写入来返回与块B1的内容对应的内容地址CA1(内容地址CA1是指定和引用块B1的存储位置的数据(引用数据)),所以数据写入部分11向存储器中暂时存储这一内容地址CA1。这一地址将被称为“0级地址”CA1。
此后,继续以上描述的块B1(实际数据)的写入,并且在收集一些“0级地址”CA1时,如图4(c)中所示向在存储设备20中的预定区域中写入包括内容地址CA1的中间块B2。然后,根据中间块B2的数据内容,如图4(c)中所示存储指定和引用中间块B2的存储位置的内容地址CA2作为“1级地址”CA2。最后,如图5中所示向存储设备20中在三级树结构中存储请求写入的数据。
在如以上描述的那样向存储设备20中在三级树结构中存储文件时,数据写入部分11执行提交,从而使得应用30可以访问文件。通过这一提交,应用30可以访问顶层,并且形成从顶层到底层的实际数据的路由,也就是说,配置快照树。例如,在执行如图5中所示的快照树的提交时,首先用引用数字W1写入配置文件的部分的块,并且在完成写入之后,提供引用块的存储位置的“0级地址”(箭头A0)。此后,用引用数字W2写入引用多个“0级地址”的存储位置的“1级地址”(箭头A1)。最后,用引用数字W3写入作为到“1级地址”的路由的留置路由(retention route)。
这时,在顶层的留置路由中包括指定这一快照(即这一文件)的搜索关键字“文件Sk”。搜索关键字“文件Sk”包括指定相同文件的文件指定信息(数据指定信息)和代表文件的版本的版本信息(更新信息)。
另外,在改变、更新和存储文件的内容时,数据写入部分1向存储设备20中新存储与改变的实际数据对应的块。在另一方面,在存储已经在存储设备20中存储的块作为在更新之后的文件的实际数据时,数据写入部分11并不新存储实际数据而是引用已经存储的块的内容地址CA1并且使用用内容地址CA1引用的存在的块作为待新存储的实际数据。因而,防止相同内容的块(实际数据)的重复存储。
如以上描述的那样,在更新文件时,新存储作为改变的实际数据的块,并且新存储引用块的内容地址CA1。因此,改变在以上描述的中间块中存储的“0级地址”,也改变包括这一中间块的内容地址的“1级地址”,并且新创建快照。也就是说,每当文件被更新时,数据写入部分11创建与文件的每个更新版本对应的快照。
因此,每当创建快照时,数据写入部分11生成在访问快照的留置路由中包括的以上描述的“搜索关键字”。这时,在“搜索关键字”中包括的文件指定信息是与在文件相同时相同的信息,并且版本信息每当文件被更新时由增加“1”的数值代表。例如,“搜索关键字”是如下信息,该信息为组合作为文件指定信息的“S”和作为版本信息的数值“1”等,并且生成“搜索关键字”,从而使得版本信息部分每当文件被更新时以“S1”、“S2”、“S3”…“Sk”的方式从初始值“1”增加1。
因此,在存储系统1中,在一个文件被多次更新时,存储与文件的旧版本和新版本对应的多个快照。
另外,数据取回部分12基于上述搜索关键字从存储设备20取回由应用30请求取回的文件的最新版本。这时,数据指定部分13引用“搜索关键字”的版本信息的值并且搜寻文件的最新版本。
具体而言,首先,对于包括指定请求取回的文件的文件指定信息的搜索关键字,数据指定部分13按照i(i代表等于或者大于0的整数)值的增加顺序检查包括值为“2i”的版本信息的搜索关键字是否存在于存储设备20中。也就是说,通过按照顺序“0”、“1”、“2”、“3”、“4”…增加i的值,数据指定部分13检查包括与“2i”所取的值“1”、“2”、“4”、“8”、“16”…一致的版本信息的搜索关键字是否存在。
这里,例如,假设如图6(a)中所示与i=4对应的版本信息“16”存在,但是与i=5对应的版本信息“32”不存在,数据指定部分13随后将存在的版本信息的为2i的最大值设置作为第一版本信息(第一更新信息),并且将为2i+1的值设置作为第二版本信息(第二更新信息)。在这一情况下,数据指定部分13设置“16”作为第一版本信息并且设置“32”作为第二版本信息。然后,数据指定部分13计算在已经被设置的第一版本信息“16”与第二版本信息“32”之间的中间值,并且执行检查中间值“24”是否作为版本信息存在的更新信息搜索过程。
在中间值“24”存在的情况下,数据指定部分13执行设置中间值“24”作为新第一版本信息的中间值替换过程。然后,数据指定部分13计算在新第一版本信息“24”与第二版本信息“32”之间的中间值,并且执行检查中间值“28”是否作为版本信息存在的“更新信息搜索过程”。在另一方面,在中间值“24”不存在的情况下,数据指定部分13执行设置中间值“24”作为新第二版本信息的“中间值替换过程”。然后,数据指定部分13计算在第一版本信息“16”与新第二版本信息“24”之间的中间值,并且执行检查中间值“20”是否作为版本信息存在的“更新信息搜索过程”。
通过反复地执行以上已经描述的更新信息搜索过程和中间值替换过程,数据指定部分13可以从在已经首先设置的第一版本信息与第二版本信息之间的值之中指定在存储设备20中存在的版本信息的最大值。例如,通过如由图6(b)中的箭头所示跟随版本信息的值,数据指定部分13可以搜索相应版本信息的值。
这里将参照图7描述由数据指定部分13搜索出版本信息的最大值的过程的示例。图7(a)示出版本信息的最大值是“27”的情况。在这一附图中,在由虚线绘制的方形以内的版本信息的值代表在存储设备20中不存在的值。在图7(a)的示例中,首先,在搜索为2i的值时,数据指定部分13发现“16”存在但是“32”不存在。随后,数据指定部分13搜索出在“16”与“32”之间的中间值“24”,并且由于中间值“24”存在,所以数据指定部分13搜索出在“24”与“32”之间的中间值“28”。这时,由于“28”不存在,所以数据指定部分13搜索出在“24”与“28”之间的中间值“26”。由于“26”存在,所以数据指定部分13搜索出在“26”与“28”之间的中间值“27”。由于“27”存在,所以数据指定部分13指定“27”作为版本信息的最大值。
另外,图7(b)示出版本信息的最大值是“24”的情况。在这一示例中,首先,通过搜索为2i的值,数据指定部分13发现“16”存在但是“32”不存在。随后,数据指定部分13搜索在“16”与“32”之间的中间值“24”,并且由于“24”存在所以搜索出在“24”与“32”之间的中间值“28”。由于“28”不存在,所以数据指定部分13搜索出在“24”与“28”之间的中间值“26”。由于“26”不存在,所以数据指定部分13搜索出在“24”与“26”之间的中间值“25”。由于“25”不存在,所以数据指定部分13指定在已经跟随的值之中最终存在的“24”作为版本信息的最大值。
通过这样指定版本信息的最大值,有可能指定与指定的值的搜索关键字对应的快照作为最新版本的快照。然后,数据取回部分12可以取回由可以从最新版本的指定的快照引用的实际数据配置的文件。
另外,存储系统1的数据删除部分14以任何定时操作,并且删除在存储设备20中存储的快照之中不再被使用的旧版本的快照。设置这一数据删除部分14以用于节省存储容量,因为在根据本发明的内容可寻址类型的存储系统1中更新文件时接连地新存储数据。
数据指定部分13也执行指定将由数据删除部分14删除的旧版本文件(也就是待删除的旧版本快照)的过程。具体而言,首先,数据指定部分13在如以上描述的那样指定版本信息的最大值时检查值为2i的版本信息是否存在,并且指定在存储设备中存在的值为2i的版本信息作为非删除目标版本信息(非删除目标更新信息)。
将参照图8描述指定非删除目标版本信息的过程的示例。图8(a)示出版本信息的最大值是“1”的情况的示例。在这一情况下,2i按照增加顺序取值“1”、“2”、“4”、“8”,并且这些值的版本信息存在。因此,与这些值的版本信息“1”、“2”、“4”、“8”对应的快照被称为“地标快照”,并且每个快照在图8(a)中具有引用符号L。另外,在如以上描述的那样搜索出版本信息的最大值的情况下,在跟随中间值“12”和“10”之后最终搜索出版本信息“11”作为最大值。由于在中间值“12”和“10”之中的“10”存在,所以与版本信息“10”对应的快照被视为“指导快照”并且在图8(a)中具有引用符号G1。另外,数据指定部分13将版本信息的最大值“11”的快照称为“最新近快照”并且在图8(a)中具有引用符号Mr。
数据指定部分13指定与如以上描述的那样指定的“地标快照”、“指导快照”、“最新近快照”对应的版本信息“1”、“2”、“4”、“8”、“10”、“11”作为非删除目标版本信息。在另一方面,数据指定部分13将与其他版本信息“3”、“5”、“6”、“7”、“9”对应的快照称为“无兴趣快照”并且在图8(a)中各自具有引用符号U。
也将描述其中版本信息的最大值是“15”的图8(b)的示例。在这一情况下,首先,将与版本信息“1”、“2”、“4”、“8”对应的快照称为“地标快照”并且各自具有引用符号L。另外,将与在如以上描述的那样搜索出版本信息的最大值时跟随的中间值“12”和“14”对应的快照称为“指导快照”并且分别具有引用符号G1、G2。另外,作为版本信息的最大值的“15”的快照被称为“最新近快照”并且具有引用符号Mr。因而,指定与“地标快照”、“指导快照”、“最新近快照”对应的版本信息“1”、“2”、“4”、“8”、“12”、“14”、“15”作为非删除目标版本信息。在另一方面,将与其他版本信息“3”、“5”、“6”、“7”、“9”、“10”、“11”对应的快照称为“无兴趣快照”并且各自具有引用符号U。
数据指定部分13向数据删除部分14通知这样指定的非删除目标版本信息。然后,数据删除部分14从删除目标排除与作为非删除目标版本信息指定的版本信息(例如,图8中的引用符号L、G1、G2、Mr)对应的快照。也就是说,即使以上提到的快照是旧版本的快照,数据删除部分14仍然不删除它们而在存储设备20中留下快照。这是为了在存储设备2中留下将稍后在数据指定部分13稍后搜索出版本信息的最大值时被使用的版本信息。
在数据指定部分13如以上描述的那样搜索出版本信息的最大值时被称为“地标快照”和“指导快照”的快照是已经被搜索出的版本信息的最大值。也就是说,在数据指定部分13通过上述方法搜索出最大值的版本信息时被追踪的版本信息的快照将被称为“途经快照”。图9示出在搜寻最大值的版本信息的值时追踪的版本信息的示例,也就是“途经快照”。
另外,数据指定部分13也具有在比最新快照更旧的快照之中指定由其他应用30访问的快照和与之有关的快照作为“回收尾部”以变成数据删除部分14的非删除目标的功能。这一方法利用由数据写入部分11执行的过程。
这里,将描述数据写入部分11还具有的功能。在写入最新快照时,数据写入部分11指定例如与数据取回部分12配合在旧版本的快照之中被访问的快照的版本信息。然后,数据写入部分11计算“回收尾部长度”,该回收尾部长度是代表被访问的快照的版本从最新快照有多么最新的信息。此后,数据写入部分11向待新写入的最新快照的留置路由中存储“回收尾部长度”。
然后,数据指定部分13取回在最新快照的留置路由中存储的“回收尾部长度”、指定从最新快照的版本信息的值上至按照“回收尾部长度”的值更小的值的版本信息作为访问目标版本信息(访问目标更新信息)并且将与访问目标版本信息对应的快照称为“回收尾部”。然后,数据指定部分13向非删除目标版本信息中包括与“回收尾部”对应的版本信息。另外,数据指定部分13也向“回收尾部”中包括“回收尾部”的途经快照并且向非删除目标版本信息中包括其版本信息。
这里,将参照图10和图11描述数据指定部分13的上述过程的示例。图10的示例示出最新快照的版本信息是“28”并且在快照的留置路由中存储的“回收尾部长度”是“3”的情况。在这一情况下,数据指定部分13指定从快照“28”上至第三的快照“25”、“26”、“27”作为“回收尾部”。另外,数据指定部分13选择作为快照“25”、“26”、“27”的途经快照的快照“1”、“2”、“4”、“8”、“16”、“24”、“26”。然而,由于在选择的快照之中的快照“1”、“2”、“4”、“8”、“16”、“24”是最新快照“28”的途经快照,所以仅指定快照“25”、“26”、“27”作为“回收快照”。
换言之,如下计算“回收尾部”:
-首先,选择由用于快照“28”的等于3的“回收尾部长度”指定的快照“25”、“26”、“27”;
-加上快照“25”、“26”、“27”的路径快照“1”、“2”、“4”、“8”、“16”、“24”、“26”;以及
-减去最新快照“28”的路径快照“1”、“2”、“4”、“8”、“16”、“24”。
因而,在上述情形中的“回收尾部”是“25”、“26”、“27”。
然后,数据指定部分13向非删除目标版本信息中包括被指定作为“回收尾部”的快照“25”、“26”和“27”的版本信息。因而,也从数据删除部分14的删除目标排除“回收尾部”的快照。
另外,图11的示例示出如下情况,该情况为最新快照的版本信息是“26”并且在快照的留置路由中存储的“回收尾部长度”是“7”。在这一情况下,数据指定部分13指定从快照“26”上至第七的快照“19”至“25”作为“回收尾部”。另外,数据指定部分13选择作为快照“19”至“25”的路径快照的快照“1”、“2”、“4”、“8”、“16”、“18”、“20”、“22”、“24”。然而,由于在选择的快照之中的快照“1”、“2”、“4”、“8”、“16”、“24”是最新快照“26”的途经快照,所以仅指定快照“18”至“23”和“25”作为“回收尾部”。
换言之,如下计算“回收尾部”:
-首先,选择由用于快照“26”的等于6的“回收尾部长度”指定的快照“19”至“25”;
-加上快照“19”至“25”的路径快照“1”、“2”、“4”、“8”、“16”、“18”、“20”、“22”、“24”;以及
-减去最新快照“26”的路径快照“1”、“2”、“4”、“8”、“16”、“24”。
因而,在上述情形中的“回收尾部”是“18”至“23”和“25”。
然后,数据指定部分13向非删除目标版本信息中包括被这样指定作为“回收尾部”的快照“18”至“23”和“25”的版本信息。因而,也从数据删除部分14的删除目标排除“回收尾部”的快照。
数据删除部分14可以在与被指定作为非删除目标版本信息的版本信息对应的快照之中删除与实际数据等效的底层的块。也就是说,数据删除部分14可以仅留下而未删除如下信息,可以从该信息知道被指定作为非删除目标版本信息的快照的版本信息。例如,数据删除部分14可以仅留下快照的顶层的留置路由的信息并且删除其他信息。
这一示例性实施例举例说明一个文件由一个快照配置的情况,但是一个快照可以配置一个文件的部分的数据(存储数据)。另外,一个快照不限于形成于三级树结构中并且可以具有任何数据结构。
<第二示例性实施例>
以下将以报告的形式描述本发明的第二示例性实施例。
<章节1>
(引言)
内容可寻址存储(CAS)是如下存储模型,在该存储模型中,持久保存、不可变的数据块通过从它们的内容推导的地址可取回。这与传统块存储库(比如硬盘驱动(HDD))形成对照,在这些块存储库中,块用它们的位置来寻址。通常用密码哈希函数(比如MD5或者SHA-1)生成在CAS系统中的基于内容的块地址。那些函数高效地将块的内容概括成少数字节,从而使得在高概率下,两个不同块具有不同概要。作为结果,基于内容的地址允许用大的置信度唯一地标识块。
这样的方式的主要优点之一是数据去重复:在请求写入块时,它的内容地址允许系统检查是否已经存储了相同块。如果相同块已经在系统中存在,则无需写入数据。在效果上,可以节省大量盘空间。这一特征使CAS对于特定类的应用有吸引力:备份和存档。
在备份和存档应用中运用CAS还受如下事实激发,该事实为可以用可伸缩、分布式方式“HYDRA09”、“Venti”、“Centera”、“DeepStore”有效地构建CAS系统。由于可以运用许多机器,所以可以用这样的方式创建具有大量盘空间的系统。另外,主要通过写入吞吐量测量的性能应当随着新节点的添加而增加。最后,分布式系统与集中式系统比较对于故障更健壮。
虽然已经开发了少数CAS系统,但是不存在用于它们的标准化API。另外,它们通常仅提供低级块接口,这些块接口需要大量努力以便对用于以有效方式存储和管理用户数据的方法编程。因此,通常引入抽象化层以提供方便接口。直观抽象化是既被程序员良好理解又在存在的应用中常用的文件系统。这样的文件系统的示例是在NEC HYDRAstor系统“HDRYA09”上面工作的HydraFS“HFS”。
由于存在的基于CAS的文件系统的典型目标应用是数据备份和存档,并且由于那些文件系统的下层块存储库提供巨大数据空间、高性能和可靠性,所以文件系统必须主要聚焦于完全利用它们的下层块存储库的性能。换言之,那些系统的目标是最大化读取-写入吞吐量以便最小化备份和数据取回的持续时间。
然而,也存在对于另一类型的文件系统的需要:提供高可用性的事务文件系统。这样的文件系统为各种可能的去耦合、分布式应用所需要,这些应用需要以可靠方式存储一些持久数据。例如,对在CAS系统中存储的数据执行一些操作的应用可能需要持久地存储它的元数据并且可以依赖于不断可用的这一元数据。
也可以使用这样的事务文件系统作为在互不了解的不同应用之间的持久通信介质。例如,它可以用来确定和传送分布式资源的权属。
(1.1.贡献)
本文呈现“Hydra事务文件系统”(缩写为“HydraTFS”)-在分布式系统HYDRAstor“HYDRA09”上面的高度地可用的事务文件系统。文件系统操作的事务方式覆盖从文件内容的修改到改变元数据结构的动作(例如,创建或者去除文件和目录)的广泛范围。无论何时中断事务,对于其他用户透明地自动回滚结果。另外,执行破碎(broken)事务的应用可以从未再次重启-并且甚至在这样的情况下执行回滚。借助下层CAS系统的特征实现这一特征:对于故障的健壮性、原子性和垃圾收集。
允许HydraTFS聚焦于可用性和原子性的下层假设是HydraTFS被相对罕见地使用并且它的使用未处于应用的关键路径上。因此,没有涉及HydraTFS的操作的延时的特定要求。然而,在HydraTFS中的文件可以由大量数据(即上至数百吉字节)构成,并且因此文件操作的带宽是一个重要问题。
(1.2.文章概述)
其余章节的组织如下:
章节2呈现HYDRAstor块存储系统的一般概述和它的对于HydraTFS必需的方面。章节3提供HydraTFS的要求的概述。在章节4中呈现HydraTFS的概述。三个随后章节提供对HydraTFS如何工作的详细描述。章节5描述在由客户端以隔离方式预备的快照中的客户端数据的结构,该快照是文件的单个版本。章节6呈现文件作为快照的汇集。该章节包含对如何可以将快照原子地提升至文件的主版本以及如何取回主文件版本的描述。
最后,章节7示出如何将文件组织成文件系统的分级结构。章节8呈现已经被实施的HydraTFS原型的评估。章节9讨论有关工作。最后,章节10总结文章。
<章节2>
(HYDRAstor系统)
这一章节提供作为用于HydraTFS的块存储库使用的HYDRAstor的一般概述。
(2.1.系统模型)
系统由两层构成(见图12)。(图12:HYDRAstor的布局。两层-呈现访问节点和存储节点。在位于存储节点的盘上存储数据。)
在对于用户不可直接访问的存储节点(SN)的网格中存储客户端数据。高层由提供数据访问API的一个或者多个访问节点(AN)形成。除了用于用户的用于HYDRAstor的访问点之外,在HYDRAstor上面运行的访问节点主机驱动器和应用、特别地为HydraTFS在一个或者多个这样的机器上工作。
(2.2.数据组织)
在不可变、尺寸可变和内容寻址的块中存储HYDRAstor中的数据。
存在三个类型的块(见图13):
-普通块,
-留置根,
-删除根。
(图13:在HYDRAstor中的数据组织。阴影矩形是数据块,虚线方形是块指针(它们指向的块的内容地址)。)
普通块是基本块,这些基本块存储由用户提供的原始数据(例如,图13中的块D、J、I)。普通块也可以包含指向先前写入的普通块的指针(也就是这些块的内容地址)的阵列以及(或者取代)数据(例如,图13中的块A、B、F)。这允许在简单有向非循环图(DAG)中组织块。与数据相似,在块地址计算的过程中包括存储的地址。换言之,块的地址依赖于在块中的数据和指向在块中存储的其他块的指针二者。
留置根除了数据和内容地址之外还包含唯一、用户指定的搜索关键字。搜索关键字用来取回块。因而,留置根常被称为可搜索块。不同于普通块的地址,每个留置根的内容地址未向用户暴露。换言之,留置根不能被任何其他块指向。留置根的目的是作为普通块的DAG的访问点并且作为用于以用户友好方式查找DAG的手段。
(2.3.块的删除)
在HYDRAstor中的一个重要问题是未立即删除单个块。作为替代,周期性地执行所谓的空间回收过程-垃圾收集器。它的任务是删除以下块:
-通过写入具有相同搜索关键字的被称为删除根的特殊块来标记用于删除的留置根,
-从活的(未被标记用于删除的)留置根不可达的普通块。
删除根因此是用于待删除的块的标记符。在图13中所示的示例中,块A、D、E、J、K将在删除之后保活,因为它们从活的留置根sk1可达。sk1本身也将存活,因为它没有对应的删除根。转而,将删除其余块。块C、I、H、N必须被删除,因为它们从任何留置根完全不可达。留置根sk2被删除,因为存在对应的删除根。
因而,将删除块B,因为它变成从活的留置根不可达。因而,与块B和C一起也删除块F和G,因为它们变成未被任何块指向、因此也未被任何留置根指向。出于相似原因,也删除块L和M。删除和有关问题的细节超出本文的范围。
(2.4.接口)
使用专用库从访问节点访问HYDRAstor。虽然HYDRAstor为分布式,但是这一事实对于客户端透明。接口如下:
(2.4.1.写入普通块)
HYDRAstor写入由用户供应的原始数据或者指针的矢量(可能是数据和指针二者)。作为回复,它提供写入的块的内容地址,该内容地址然后可以用作在另一普通块或者留置根中存储的指针。无需实际写入块。在相同块已经存在于HYDRAstor中的情况下,它将最可能被去重复。也就是说,根本不会保存块,并且作为替代,将向用户返回已经写入的相同块的内容地址。然而,未保障这一行为,并且可能发生在系统中存在两个相同块。然而,这一事实对于客户端透明并且未涉及到任何正确性问题。
(2.4.2.写入普通块)
用户提供待读取的块的内容地址。作为答复,HYDRAstor返回块内容-数据和指针。
(2.4.3.写入留置根)
用户除了原始数据和内容地址之外还提供用于待写入的块的搜索关键字。如果具有这样的关键字的留置根已经存在于HYDRAstor中,则无论其余内容是否相同都返回错误。与普通块对照,写入留置根是原子的,也就是说,如果具有相同搜索关键字但是具有不同内容的块的两个或者更多写入并发发生,则至多一个写入者获得成功而其他写入者获得块已经存在的信息。
(2.4.4.读取留置根)
用户提供搜索关键字并且作为答复接收块内容。在请求的块不存在或者被标记用于删除(也就是说,它被删除根指向)时,返回错误(分别为“不存在”和“被标记用于删除”)。
(2.4.5.标记留置根以用于删除)
写入指向留置根的删除根。用户可以写入指向单个删除根的多个删除根。在这样的情形中,删除根将被去重复。读取或者写入被标记用于删除的留置根返回块被标记用于删除的信息。
(2.5.特性和限制)
由于HYDRAstor被设计用于备份和数据存档,所以它的主要特征是高写入吞吐量。用于4-SN和4-AN HYDRAstor的未压缩数据的写入吞吐量达到450Mb/s“HYDRA09”。这一值是指非重复数据和从所有访问节点执行的写入。当在写入的流中的重复块的百分比增加时,吞吐量逐渐增加从而在重复块为百分之100时达到900MB/s。
写入压缩的数据给予甚至更佳结果。在压缩比为33%时,用于0%和100%重复流的带宽分别达到610MB/s和1150MB/s。
读取带宽略微更低。它对于HYDRAstor提供非常快的读取并非如此重要,并且因此尚未如此密集地优化它。
读取延时近似为150ms。写入操作的延时转而达到约1500ms。写入延时并不依赖于重复块的百分比。这样的行为由HYDRAstor的流控制引起,该流控制努力在恒定水平上保持延时,从而可能增加或者减少利用的带宽。
块大小可以从1字节和0个内容地址到65536字节和5120个内容地址变化。
HYDRAstor的总容量依赖于安装的存储节点和盘的数目。由2个访问节点和4个存储节点构成的可用于客户的中等规模的系统可以存储在24与48特字节之间的非重复数据“Hydra模型”。
最大可用系统(55个访问节点和110个存储节点)具有1.3PB的容量
<章节3>
(HydraTFS要求)
HydraTFS已经被设计用于解决为HYDRAstor构建的应用的具体目标,这些目标未被用于HYDRAstor的存在的文件系统解决。因而,该设计已经被定制用于主要适应这些应用的需要。为了说明HydraTFS的要求,讨论这些应用。
(3.1.概述)
应用可以在多个访问节点上工作。可以隔离应用的在不同机器上运行的实例,也就是说,它们无需协调。另外,即使没有在访问节点之间的物理连接可用,应用仍然应当工作。
(3.2.使用情况)
存在的应用将用两种方式使用HydraTFS:作为用于元数据的数据库和作为用于存储部分结果以实现检查指示(checkpoint)和恢复的方法。
(3.2.1.用于元数据的DB)
在第一使用情况下,HydraTFS用来存储若干千字节的数据记录。每个记录对应于应用的独立任务,并且因此记录本身独立。一些记录被保持于存储器中,并且在被修改时必须被保存到Hydrator以便变成持久。
(3.2.2.用于部分工作结果的存储)
在第二使用情况下,可以长时间段工作的批处理需要以持久方式周期性地检查指示它的结果以便能够在被暂停之后或者在崩溃之后取回它们。存储的部分结果是可以是任何大小的数据流。在任务继续时在流的结束追加数据。在任务被恢复时,从开始读取整个流,并且以后进一步检查指示追加出现。
必须在HYDRAstor中持久地存储向流追加的数据的部分。
(3.2.3.列举和删除存储的数据项目)
以上应用必须能够列举它们已经存储的所有数据项目(DB记录和部分工作流二者)。例如,这是在应用启动期间需要的。另外,可能出现需要列举已经由应用实例从另一访问节点保存的数据项目。它可能是在崩溃的访问节点的职责被另一访问节点接管的情况下需要的。也允许应用实例崩溃并且从未再次到达特定访问节点。在这样的情形中,由应用存储的数据项目即使未被接管也仍然必须被删除。因而,为了被删除,必须首先列举它们。
(3.3.要求)
(3.3.1.延时和吞吐量)
在HydraTFS上的操作相对罕见地被执行并且未在应用的关键路径上。因此,低延时不是主要要求。然而,可能需要高吞吐量,因为应用可以写入大量数据,也就是上至数百吉字节。
(3.3.2.并发性)
在小节3.2.1和小节3.2.2中描述的使用情况中,每个DB记录或者数据流多数时间由单个过程使用。然而,在过程被视为崩溃时,并发访问可能出现。并发访问的出现可能具有两个原因。
首先,崩溃的过程可能在HYDRAstor中留下仍然继续被正常处理的一些请求。它们可能干扰接管崩溃的过程的职责的另一过程的请求。
第二,在访问节点上运行的过程可能不正确地被视为崩溃-例如,由于网络故障。然而,它仍然可以与存储节点连接并且与HYDRAstor成功配合。
并发访问如果未被适当处理则可能引入可能使系统不可靠的数据不一致。这在商用产品比如HYDRAstor中不可接受,并且因此必须在HydraTFS的设计中解决并发性问题。
<章节4>
(HydraTFS概述)
(4.1.在HYDRAstor系统中的放置)
在HYDRAstor系统中,HydraTFS过程与它已经被设计用于的应用的过程一起在访问节点上被执行。它可以在任何数目的AN上并发地被执行。
在HYDRAstor系统中的所有HydraTFS过程在单个文件系统上操作。整个文件系统被持久地存储于HYDRAstor中并且在同等权利下从所有访问节点可访问。另外,HydraTFS的架构无需在访问节点之间的连通以处理并发性。换言之,经由持久块存储库执行整个过程间通信。因此,仅需在每个访问节点与存储节点的网络之间的连通。
(4.2.文件系统结构)
这一小节提供HydraTFS的结构的由下至上描述。
(4.2.1.记录)
从用于用户供应的数据的单个原子结构的定义开始。与对字节流操作的经典文件系统接口形成对照,HydraTFS被设计用于对不可划分的数据组块操作。也就是说,数据的片段一旦被写入就仅可作为整体被读取。将把这样的片段称为记录。这简单地是包含(由字节序列代表的)对象和内容地址(块指针)的结构。
记录与在HYDRAstor中的普通块相似。然而,单个记录不等效于单个块。恰好相反,允许在单个HYDRAstor块中保持多个记录以及跨越许多HYDRAstor块展开一个大记录二者。因此,没有关于单个记录的大小的下限,并且在理论上,单个记录可以覆盖整个文件。例如,在小节3.2.1中描述的使用情况下,整个数据库记录可以被放入单个记录中并且然后也作为整体被取回。
(4.2.2.文件快照)
文件快照(或者简称为快照)是由单个客户端过程创建的一致记录序列。事实上,在HYDRAstor中,它由指向普通块的DAG的留置根代表。在文件为小的情况下,该表示仅为留置根。
在章节5中详细呈现在单个快照中的记录的组织。对快照允许的I/O操作是依次读取记录和在结束追加新记录,由此形成新快照。
可以提交这样的新快照以便变成持久。将在下一小节4.2.3中再次提到这一操作。然而,在提交继续之前,用户以隔离方式执行对快照的I/O操作。在构造之下的快照未以任何方式与其他快照或者写入的任何其他HYDRAstor块冲突。事实上,它甚至直至它被提交才可被其他过程察觉。快照一旦被提交就不能被修改,因为在HYDRAstor系统中的块不可变。相同论证适用于属于在构造之下的快照的所有块。在快照的写入器在提交快照之前崩溃时,已经在构造快照期间写入的普通块将保留于HYDRAstor中。
然而,只要未由于去重复而从别处引用它们,则将在HYDRAstor的垃圾收集过程期间删除它们。每单个快照的数据量可能显著——上至数百吉字节。因此,需要读取和追加二者以允许高吞吐量。
(4.2.3.文件)
在HydraTFS中的文件是快照的汇集。在它们之中,最新近快照是文件的主导版本-它是上次成功提交的快照。也就是说,在文件被访问时,使最新近快照可用于由用户读取。其他快照被称为过时快照。然而,它们中的一些快照仍然可以由在另一快照变成最新近之前开始读取它们的用户访问。在另一方面,无论用户何时开始访问文件,可用于他的仅有快照是最新近快照。
提交新快照是用新快照原子替换最新近快照。它是事务操作、也就是说,在许多用户读取最新近快照并且然后他们都尝试提交新快照时,仅一个用户将成功。其余用户将必须取回已经为新的最新近快照并且再试。化解数据冲突取决于应用。
提交的原子性来自如下事实,该事实为它实质上是在HYDRAstor中的留置根写入。因此,没有不一致状态是可能的-成功写入块从而构成新的最新近快照或者在失败的情况下未写入。
(4.2.4.文件系统)
将HydraTFS组织成由文件和目录组成的结构。这一文件系统布局使HydraTFS的使用对于用户更方便。每个目录可以存储无限数量的其他目录。文件系统树的深度也是无限的。换言之,文件系统结构可以自由扩展。
目录内部与普通文件相似,但是具有特殊内容。与普通文件相似,它的内容的修改是事务的。因此,目录结构(并且因此整个文件系统树)总是在一致状态中。
向用户隐藏每个目录的内容。作为替代,暴露典型文件系统操作,比如创建新文件、去除文件或者列举目录。
文件系统结构实现高效并且以可伸缩方式组织文件。例如,可以用若干更小目录替换经常被访问的目录。作为结果,减少在涉及到提交目录内容的新版本的文件系统操作期间存在的并发性问题。不同普通文件或者目录从并发性观点来看是分离的。
(4.3.概要)
概括而言,聚焦于该设计如何对应于两个主要要求:全局名称空间和事务操作。
(4.3.1.)
术语“名称空间”意味着所有访问节点在同等权利下在文件系统上操作并且访问文件系统的相同“版本”。在由访问节点之一组成的文件系统上的操作的效果在提交之后从所有其他机器可见。然而,操作并不由任何全局首领协调。每个访问节点独立操作并且无需与其他访问节点的网络连通。
在HYDRAstor上工作的另一文件系统-HydraTFS当前未提供这样的全局名称空间特征。文件系统一次仅从单个访问节点可访问。
(4.3.2.事务操作)
在HydraTFS中,修改普通文件或者目录的内容的操作是事务的。如同在数据库中,将可靠的事务必须保障四个性质:原子性、一致性、隔离和耐久性“Ullmann”。聚焦于如何在HydraTFS中实现这些性质。
“隔离”:在创建新快照时,在提交之前,在HYDRAstor中它被实质上代表作为普通块的结构。这些块未被任何其他过程可达。用于引用它们的仅有方式是提供恰当内容地址-但是那些被保持于写入过程的存储器中。然而,另一过程可以获得内容地址。但是这仅在其中所有块将被去重复的情形中仅能通过写入它们的相同结构来实现。这不是问题,因为块不可变并且写入重复的过程无法影响预备事务的其他过程。更准确而言,写入重复块的过程甚至不能察觉另一过程也在预备快照以及相同块已经存在于系统中。因此,这一情形未导致任何问题。
“原子性和耐久性”提交操作如它已经被说明的那样实质上是留置根的写入,该留置根是在构成快照的块的结构中的最后的块。原子性和耐久性直接由HYDRAstor保障。成功保存留置根从而使提交成功,或者它失败从而留下普通块未被留置根引用。在失败之后,将在垃圾收集过程期间从HYDRAstor删除普通块。换言之,在提交失败的情况下,自动回滚数据-它无需来自HydraTFS的任何照看。
“一致性”根据已经在小节4.2.3中陈述的那样,在许多用户读取最新近快照时,预备文件的新版本并且试着提交它,该实现方式保障至多一个用户将成功。这保障数据的一致性,因为为了提交快照,必须首先取回最新快照。换言之,修改文件的过程不能提交如下新版本而未读取在最新版本中的修改,该新版本是过时版本的变换的结果。然而,数据冲突必须由应用化解。
<章节5>
(快照)
文件的快照(在小节4.2.2中已经介绍)是由客户端独立创建的记录的汇集。在被提交时,这一汇集变成文件的主导版本。在下一章节中详细讨论提交操作。在这一章节中,转而聚焦于从快照读取记录和向快照写入它们。
目标是提供一种实现在快照的结束追加记录并且依次读取这些记录的方法。应当有可能向新的空快照和向已经包含一些记录的快照追加记录。每单个快照的数据量可以显著-上至数百吉字节。因此,需要读取和追加二者以实现高吞吐量。
由于在提交操作之前,快照仅对于对它操作的客户端可见,所以追加操作未引入任何并发性问题。
(5.1向快照写入)
首先,假设被讨论的快照为空并且客户端尝试执行一些初始写入。客户端请求HydraTFS写入一些记录。在存储器中缓冲这些(图14(a))。在存储器缓冲器的大小超过某个限制时,向HYDRAstor写入包含缓冲的内容的新普通块。记忆由0这样的写入所返回的内容地址。将把这样的地址称为0级地址。
此后,可以继续客户端写入,作为结果,收集更多0级地址(图14(b))。
在记忆的0级地址的数目等于或者超过在单个块中相配的内容地址的最大数目时,向HYDRAstor写入包含这些内容地址的中间块。再次记忆这一个块的内容地址。然而,这时作为1级地址(图14(c))。作为结果,可以从存储器清除刚才已经向HYDRAstor保存的0级地址。以这一方式,获得三级树,该三级树具有包含客户端的记录的叶节点和包含指向更低级节点的指针。
为了简化而未支持更高级树。
图14:构建快照的树结构。虚线块是尚未向HYDRAstor保存的块-它们的内容仍然仅在存储器中。阴影块是具有客户端的记录的块,每个记录由数据和/或指针构成。
(5.2.提交快照的内容)
请注意,在前一小节中描述的算法未保障由用户追加的记录在物理上被存储于HYDRAstor中。恰好相反,仍然可以缓冲用户的记录中的一些记录,并且仍然可以在存储器中保持一些内容地址(0或者1级)。另外,该结构未被任何留置根指向。这一情形将造成在最近垃圾收集期间删除整个快照的内容。
为了保证在HYDRAstor中存储的数据持久,必须提交快照。这意味着作为结果,必须向HYDRAstor刷新缓冲器并且整个快照结构必须被留置根指向。具体而言,提交如下工作:
-如果树的当前高度是0(也就是说,尚未保存块),则向HYDRAstor保存存储器缓冲器的内容作为新留置根。
-如果树的当前高度是1(已经记忆了至少一个0级地址),并且一些用户数据存在于存储器缓冲器中,则向HYDRAstor写入包含缓冲器的块,并且记忆它的内容地址作为随后0级地址。此后,向HYDRAstor写入所有记忆的0级地址作为留置根的一部分。
-如果树的当前高度是2(已经记忆了至少一个1级地址),则操作递归地工作。首先,在0级块中写入缓冲器,然后,写入中间1级块,最后,保存记忆的1级地址和元数据作为留置根。请注意,在每级上可以有至多一个非持久块。
图15图示提交高度为2的快照的树的过程。写入1是对于具有客户端的记录的缓冲器的内容。在前述写入完成之后,供应0级地址,在写入2期间写入0级地址的1级块。
最后,在指向块的1级地址从HYDRAstor到达时,在写入3期间写入具有快照的搜索关键字的留置根。
图15:提交高度为2的快照的树。虚线块在存储器中并且必须被写入。其余块已经在HYDRAstor中。
在提交快照的缓冲器之后,客户端可以继续追加记录。在逻辑上,那些新数据项目与刚才提交的数据项目一起将包括下一快照。为了使下一快照持久,将必须完成下一提交(具有新留置根的搜索关键字)。因而,客户端可以将提交视为与fflush()相似的刷新操作。
在构建快照的过程在成功提交之前崩溃或者提交失败并且客户端未尝试再试的情况下,将回滚未完成的快照,也就是说,将在最近垃圾收集期间自动回收已经在HYDRAstor中存储的记录。这是因为包含这些记录的普通块未被任何留置根指向。
(5.3.快照的叶块的结构)
如更早说明的那样,记录可以由原始数据(字节)和内容地址(指针)二者构成。在向快照的每个追加期间,可以从一个字节或者一个内容地址开始保存任何数量的数据/地址。在追加之后,也允许客户端提交。如果在这样的提交之后的下一追加向新的随后HYDRAstor块添加它的记录,则客户端最后将具有由包含少量记录的过量块组成的快照:甚至每块一个记录。这样的快照除了占用比必需远远更多的空间之外还将导致耗费时间和资源的读取。
因而,已经介绍了一种用于跨越块组织记录的方法。尽管它的细节超出本文的范围,但是它的目标是以这样的如下方式在连续块中紧缩记录,该方式为将除了最后的块之外的所有块填充到它们的容量(64kB数据或者5120个地址)。
(5.4.读取快照)
读取过程始于读取恰当留置根,也就是快照的树结构的根。然后,发现按照顺序的第一叶块并且开始读取记录。快照读取操作仅仅为简单地依次读取树叶。
在读取之时,应当在存储器中高速缓存上次处理的叶块和所有它的在快照的树中的上至根的父代。这将不要求主要数量的存储器(上至三个块)。否则,如果仅在树中保持该位置,则每个随后读取将持续大量时间,因为它将由从HYDRAstor的上至三个依次读取构成。
(5.5.概要)
呈现的设计允许创建无显著数据开销的大快照并且用于以高效方式依次读取和写入快照。
(5.5.1.写入性能)
以可以促成高HYDRAstor利用率这样的方式执行追加操作。即使客户端继续发出对很小记录的追加,仍然缓冲并且在准备好时向HYDRAstor写入用于随后记录的候选。因此,在相当大的大小的组块中执行向HYDRAstor的写入。除此之外,向HYDRAstor的写入未以任何方式中断随后准备好的块的进一步追加和可能的进一步写入的过程。以上也适用于写入中间1级块。假如存储器缓冲器足够大,则追加过程可以完全利用由HYDRAstor提供的带宽。
(5.5.2.读取性能)
记录读取的性能可以显著低于写入的性能。主要原因是检查记录是否占用树中的页块需要读取先前页块。因此,该设计由于在HYDRAstor中的块读取的高延时而假设逐个读取块,这减少吞吐量。可以用预取或者通过在中间树节点中存储附加元数据来提高读取吞吐量。
<章节6>
(作为快照序列的文件)
由每个客户端过程以隔离方式执行如在章节5中描述的构建快照。仅写入最顶部块-留置根-最终影响全局名称空间并且可能与其他客户端冲突。因此,引入在预备留置根的内容(仍然使用在前一章节中定义的方法来执行)与向HYDRAstor的实际写入之间的边界线,这里将讨论这一点。由于留置根写入使新快照对于其他客户端可见,所以将把该操作称为写入快照。在(由一个或者许多客户端过程)多次提交文件时,在HYDRAstor中创建多个快照。
由于对于每个文件,多个快照可以存在于HYDRAstor中,所以问题之一是在客户端想要读取文件的情况下选择最新近快照。将把这一操作称为获得最新近快照。与写入快照相似,获得最新近快照选择和读取恰当留置根,然后向已经在前一章节中描述的负责读取单个快照的程序传递它的内容。这时将不会考虑去除文件;将在下一章节中讨论这一点。
对于写入快照/获得最新近快照操作的主要要求是修改文件的事务方式。也就是说,如果许多客户端使用获得最新近快照来读取相同快照,并且每个客户端创建新快照,并且然后所有客户端执行写入快照,则至多一个这样的操作成功。其余客户端为了它们的提交成功而必须对文件重复它们的操作-也就是说,进行获得最新近快照以刷新它们的数据、化解潜在冲突并且再试一次。这一特征保障数据一致性。将在最近HYDRAstor垃圾收集期间自动删除在未能被提交的快照中的任何普通块,因为构成它们的写入的块未被任何活的留置根指向。
在小节6.1中,呈现对于该问题的基本方式。然后,在以下小节中,逐渐改进这一解决方案。
(6.1.基本方式:快照的线性序列)
在基本方式中,将文件表示为快照的序列。初始地,文件具有0个快照。在第一提交之后,创建快照1。后继提交创建快照2、3等。相似地,最新近快照是具有最高编号的快照。从现在起将把第i个快照称为Si。
获得最新近快照简单地对于快照迭代(在HYDRAstor中执行留置根读取)并且返回存在的最后快照的内容。为了检查快照的存在,读取它的留置根就足够了。
在读取快照Si之后,可能的后继写入快照尝试写入Si+1。来自仅一个客户端的写入快照操作成功(小节2.4.3)。对于写入Si+1的其他客户端,留置根写入将不会成功。HYDRAstor将返回错误状态,该错误状态表示具有请求的搜索关键字的留置根已经存在。在这样的情形中,向客户端反馈错误状态,该错误状态表示已经被读取的快照(在这一情况下-Si)已经过时。客户端将很可能重复操作序列以化解并发性冲突。下一获得最新近快照将返回新保存的快照根Si+1(假如同时无别的任何提交)。然后,在引入读取快照的修改之后,客户端将成功提交新快照Si+2。
在成功提交之后,客户端未被迫再次进行获得最新近快照。恰好相反,如果已经提交了快照Si+1,则客户端可以执行进一步提交,并且它们将被写入作为快照Si+2、Si+3等。
在存在并发写入时,返回的最新近快照可以实际上比实际最新快照更旧。然而,这不是问题,因为如已经陈述的那样,如果客户端试着基于过时快照提交(进行写入快照),则操作将失败。以这一方式,客户端将有机会化解任何冲突并且重新尝试操作。
(6.2.改进:双二元搜索算法)
现在聚焦于获得最新近快照操作的任务并且试着改进它。给出在HYDRAstor中保存的快照序列S1,S2,…Sn。任务是高效地发现这样的序列的结束。
如读者可能已经注意的那样,在前一小节中描述的基本方式中呈现的迭代不是最优解决方案。它需要O(n)个读取。作为关于用于改进读取数目的方式的第一步骤,高效发现关于最新近快照的序列号的上界。取代对于快照根逐个迭代,可以检查快照根S20,S21,…S2k的存在。因此,如下编号2k是上界,该编号使得S2k-1存在S2k而不存在。例如,在图16a中,迭代在快照32完成,因为它在序列1,2,4,…中是不存在的第一快照。因此,32是发现的上界。(图16:双二元搜索算法。)
在已经标识界限之后,可以二元搜寻在范围(2k-1,2k)中的序列的结束(图16b)。
在图16c中,呈现样本算法执行。结果是27。在达到叶快照并且它不存在(图16d)的情况下,结果是最新近遇到的快照。换言之,所得快照可以在其中存在的相继范围如下:
-(16,32)-在发现上界之后,
-(24,32)-快照24存在,
-(24,28)-快照28不存在,
-(24,26)-快照26不存在,
-(24,25)-快照25不存在,因此结果是24。
利用以上二元搜索,将为了发现序列Sn的结束而必需的操作数目从O(n)减少至O(log(n))。
可以通过用更大基数搜索来改进以上双二元搜索算法。例如,在基数为64时,并行发出64个留置根读取。假设最新近快照编号少于264,可以发现用于在一个并行取读中的最后快照的编号的上界。可以比原有二元搜索块六倍完成算法的第二步骤,因为一次进行搜索树的6级(62=26)。这一简单优化明显减少获得最新近快照的延时。
(6.3.删除非必需快照)
存储完全序列,也就是在文件的寿命期间创建的所有快照浪费存储,尤其是因为文件大小(并且因而快照的大小)可能达到上至数百吉字节。另外,在每个快照中的客户端记录可以包含指向客户端不再需要的块的指针并且可以由HYDRAstor回收。在效果上,快照占用的空间的实际数量可以甚至更大。因此,需要一种用于减少为单个文件存储的数据量的方法。
(6.3.1选择待删除的快照)
为了介绍性的考虑,假设文件不变-也就是说,未写入新快照。
在获得最新近快照操作期间,双二元搜索算法拜访(这里-检查存在)仅快照的小子集。也可以删除其余快照。它们的存在或者不存在从获得最新近快照的观点来看未产生不同。
为了以更正式的方式定义用于删除不需要的快照的方法,现在对组成快照序列的快照分组。首先,介绍以下符号表示:
-M-最新近快照的序列号,
-N-常数,该常数使得2N=<M<2N+1,
将快照分类成以下类别:
“最新近快照”这是快照SM。
“不存在的快照”这些是所有如下快照Si,这些快照使得i>M。
“地标快照”这些是所有如下快照S2i,这些快照使得0=<i<=N。
“指导快照”最佳迭代地定义这一组:
[数学式1]
“非兴趣快照”这些是所有其他快照。
可以在图17中查看快照分类。(图17:快照分类:L-地标快照,Gk-指导快照,Mr-最新近快照,U-非兴趣快照。)
直观地,根据以上呈现的术语,双二元搜索算法的思想是首先通过对于地标快照迭代来标识N,并且然后通过对于指导快照迭代来发现M。
如可见的那样,可以安全地删除非兴趣快照,因为在搜索算法中未使用它们。另外,可以看到,在快照变成不感兴趣时,它无论序列增长与否都保持不感兴趣。由于仅有O(log(n))个兴趣快照,所以去除非兴趣快照节省大量空间。
“路径快照”
将把在搜寻SM之时被迭代的并且在系统中存在的快照(也就是说指导快照和地标快照)称为用于SM的路径快照。在图18中图示“A是用于B的路径快照”关系。该关系是及物的,因此为了可读性,仅标记用于每个快照的最高路径快照。(图18:路径快照。虚线箭头从快照指向它的具有最高编号的路径快照。)
(6.3.2.回收尾部)
现在放弃文件不变的假设并且分析在写入新快照时发生什么。
假设具有在Sk结束的快照序列。在写入新的一个快照Sk+1之后,即使Sk变成非兴趣快照,仍然不能简单地立即标记它以用于删除。尽管写入新快照,但是一个或者多个旧快照仍然可以被已经以往在它们已经是最新近快照时开始读取的某个客户端读取。如果标记它们以用于删除并且垃圾回送在HYDRAstor中继续进行,则将最终具有读取错误:读取不存在的快照。因此,想要所有用户完成读取而无后果。
这同样适用于搜寻最新近快照。不想在二元搜索的中间实现已经标记在路径上的某个快照根以用于删除。在这样的情形中,搜索结果可能严重地异常。
快照的激进删除也可以引起错误肯定提交。想象由客户端读取的快照和(由于另一客户端的操作而)变成不感兴趣的下一快照二者被标记以用于删除。然后,运行在HYDRAstor中的垃圾收集,并且以后客户端提交。提交将成功,因为在新提交的快照的位置不再有快照。
作为结论,必须确立哪些快照可以无论如何由客户端使用而哪些快照不可以。最乐观的是,可以假设所有快照仍然可以被某个客户端需要-事实上,根据当前规则,客户端可以开始读取某个快照并且从未停止,即使它长时间不是最新近快照。
显然,这是不可接受的。必须提供一种用于确定将不会被任何客户端访问的快照的方法。为此,引入时间限制Tr,在该时间限制内,客户端必须设法用获得最新近快照搜索快照、读取它并且(如果它希望则)提交新快照。时间限制在获得最新近快照开始时开始计数。因而,可以删除的快照是在多于Tr之前变成不感兴趣的所有快照。
读取和运行获得最新近快照然后精细工作,假如这些方法的实现方式如果操作持续时尚未超过时间限制则控制。提交操作的正确性转而依赖于在被客户端仍然视为最新近快照的快照之后跟随的下一快照的百分比。可以看到,如果Si在不多于Tr时间以前停止作为最新近快照,则Si+1比Si更晚、因此也在不多于Tr时间以前停止作为最新近快照。
对某个文件执行操作的每个客户端存储关于非兴趣快照的所谓的回收尾部的在存储器中的信息;这些快照也就是应当被标记用于删除、但是仍被保留以向其他潜在客户端给予足够时间来完成它们的操作的快照。
更具体而言,假设如果快照Si在写入快照SM时变成不感兴趣,则未立即标记Si以用于删除。将仅在从它的提交完成的时刻起的2Tr之后标记它以用于删除。换言之,快照将在长到足以允许所有未决客户端操作完成的回收尾部中保留。虽然在理论上,等待Tr就足够了,但是执行等待两倍之久。这是因为访问节点的时钟频率可能被偏斜。通过拖延等待,能够容许甚至严重的时间测量不准确。
“回收尾部长度”
现在聚焦于如下情形,在该情形中,使用文件并且因此也保持跟踪它的回收尾部的客户端崩溃。绝不能忘记在回收尾部中的快照,因为这将在HYDRAstor中引起严重存储泄漏。在另一方面,由于潜在大量待检查的快照而也不能从快照1开始并且在最新近快照结束检查所有快照的存在。因此,呈现一种在崩溃之后重新构建关于回收尾部的知识的解决方案。
为了取回回收尾部而需要的信息、回收尾部长度总是用快照来写入-在留置根的数据部分中。以这一方式,在崩溃之后,仍然可以回收在尾部中的快照。假设最新近快照是SM,回收尾部长度被定义为最低编号k,从而使得快照SM-1,SM-2,…,SM-k与它们的路径快照一起形成当前回收尾部的超集合。
因此,通过持久地保持回收尾部长度,可以通过取最新近快照的k个前代快照、生成它们的路径快照并且减去最新近快照的路径快照来容易地取回回收尾部。所得集合可以在事实上包含已经被回收的快照。然而,这是在垃圾回收阶段时的正常问题并且无论如何必须加以考虑。
在图19a中,回收尾部由快照:25、26、27构成。回收尾部长度是3。在重新构建回收尾部的情况下,将计算用于快照25-27的路径快照。快照25、26、27的路径快照是26、24、16、8和在图中未示出的快照-4、2、1。快照1、2、4、8、16、24也是最新近快照的路径快照。因此,未向回收尾部添加它们。作为结果,回收尾部仅由快照25-27构成。
在图19b中,转而,回收尾部长度是7(回收尾部由快照19-25生成)。将快照24计数到回收尾部长度中,但是从回收尾部排除它作为最新近快照的路径快照。未将快照18计数到长度中,但是将它包括到回收尾部中作为被计数的快照19的路径快照。快照16、8、4、2、1如同在先前示例中一样不是回收尾部的一部分,因为它们是最新近快照的路径快照。一般而言,地标快照从未是回收尾部的一部分-它们从未变成非兴趣快照。(图19:回收尾部。在方形中的编号表示存在的快照。粗体方块和箭头表示最新近快照和它的路径快照。虚线方形未被计数到回收尾部长度中、但是为回收尾部的一部分。)
“保持跟踪非兴趣快照”
如以上已经陈述的那样,使用给定的文件的每个客户端保持保持关于它的未回收的非兴趣快照的信息并且无论何时可能都标记它们以用于删除。无论何时快照被识别为不感兴趣,都向具有与当前时间加上2Tr相等的到期时间的汇集添加它。首先,标记到期的快照以用于删除(也就是说,在HYDRAstor中写入与它的快照根对应的删除根),并且在它成功之后,从汇集去除它。
“在快照操作的背景中工作”
在写入快照操作期间,计算回收尾部长度。计算基于在汇集中保持的快照和附加最新近快照-因为它在写入快照成功时也变成非兴趣快照。然后,在留置根中写入回收尾部长度,该留置根是新快照的快照根。在提交成功时,向汇集添加已经在前的最新近快照。与快照一起也向非兴趣快照的汇集最可能部分添加它的路径快照的部分-这些不是用于提交的快照的路径快照。
在获得最新近快照期间,基于从读取的最新近快照取回的回收尾部长度更新非兴趣快照汇集。在它是由这一客户端对文件执行的第一操作的情况下,初始化汇集。转而,在已经存储了关于文件的信息时,可以在由其他客户端自从上次更新起已经执行一个或者多个提交时更新它。在这样的情况下,一些新快照到达回收尾部,因为提交已经使一些快照不感兴趣。在另一方面,回收尾部可以收缩,因为并发运行的客户端可能已经更早标记一些快照以用于删除并且因此可以从汇集去除它们。在图20(20a,20b,20c)中示出这样的回收尾部更新的示例。
图20:在获得最新近快照之后更新。更新的项目是回收尾部长度和回收尾部本身-基于长度。加粗体的快照是最新近快照和它的路径快照-确信地存在的快照。在框中的快照是可能存在的快照。在虚线框中的快照是可能存在、但是未被计数到回收尾部长度的快照。
(6.3.3标记器块)
地标和指导快照-最新近快照的路径快照-可以在系统中持续大量时间(在地标快照的情况下甚至持续整个文件的寿命)。在它们的存在期间,它们仍然包含文件的一些更旧版本,这些版本可以有显著大小。然而,对于每个讨论的快照,在从它停止作为最新近快照的时刻起的Tr之后,它的作用被减少为确定通向最新近快照的路径。这激发引入标记器块。
标记器块是无内容的留置根。优化的基本思想是它们与组成留置根的镜像序列的标准快照一起被保存。可以在获得最新近快照操作中使用这一序列而不是标准快照根。现在可以回收所有地标和指导快照,只要它们在Tr时间之后不是回收尾部的一部分,如同它们为非兴趣快照一样。标记器块优化的细节超出本文的范围。
<章节7>
(将文件布置成文件系统)
将HydraTFS中的文件组织成文件系统式目录结构。这使它们的使用对于客户端更方便。另外,这样的解决方案实现高效并且以可伸缩方式组织文件。例如,无论客户端何时希望让他的私有文件存储于系统中,他可以创建用于它们的(未被任何其他客户端访问的)分离目录,并且作为结果最小化在添加或者去除文件期间的并发性问题。无别的方面(可能除了垃圾收集器-在小节7.3.2中描述-之外)将影响目录并且进行任何冲突改变。
(7.1.文件和目录)
目录被实施为向用户隐藏但是具有特殊内容的文件。因此,无论在这一章节中何时提到“文件”-都可以是指普通文件或者目录。每个目录包含与文件和子目录(它的在文件系统树中的子代)对应的条目的列表。每个条目对应于记录并且包含:
-文件的由客户端定义的名称,
-文件类型,该文件类型表示条目是否对应于普通文件或者目录,
-文件ID。
文件ID是可以在传统文件系统中被视为i节点编号的标识符。一般以它无论创建它的地点或者时间如何总是唯一这样的方式生成它。然后,使用(用快照的序列号作为后缀的)这一标识符作为用于对于快照的树结构的根保留的每个留置根的搜索关键字。
(7.1.1.文件操作)
以下操作对文件系统是可能的。
“打开存在的文件”打开文件操作在给定文件路径时返回文件句柄,即用于存在的文件的句柄。需要这样的句柄以执行所有进一步操作。文件路径是与在传统文件系统中的路径相似的串(例如,“/aDirectory/aSubdirectory/aFile”)。
在打开操作期间,必须分辨算文件路径。也就是说,必须打开从根目录开始的所有父目录并且必须读取它们的条目。例如,具有用于获得文件的文件ID的路径“/a/b/c/file”,需要读取目录c的条目。但是为了读取目录c,需要具有它的文件ID。因此,需要读取目录b等等上至文件系统根的条目。文件系统的根文件ID恒定,因此无需从任何位置取回它。
“创建文件”创建文件操作在给定文件系统结构中的父目录的文件句柄时在父目录中创建具有请求的名称的普通文件或者目录。
“访问普通文件的内容”读取文件操作在给定普通文件的文件句柄时运行获得最新近快照以搜寻文件的最新近快照并且提供对文件类型实现读取和追加操作的接口。这些是与在章节5中描述的相同操作。提到的接口也提供提交文件操作,该提交文件操作运行对于文件内容的提交操作并且然后进行写入快照以便创建新普通文件的快照。
“列举目录”列举目录操作返回在由文件句柄指定的目录中存在的普通文件和目录的列表。
“去除文件”去除文件操作持久地标记文件或者目录以用于去除。暂时省略用于文件去除的方法。由于它略微更复杂,所以稍后将分离地描述它。
(7.1.2.文件系统操作的原子性)
从不同访问节点并行访问文件系统并且因此访问每个文件。特别地,可以并发执行修改目录内容的操作(创建文件和去除文件)。
由于想要目录条目一直一致,所以在对它们执行修改之时,使用在前一章节中描述的事务机制。在事务失败的情况下,简单地重复操作-也就是说,读取目录内容、执行必需修改以及写入具有目录条目的新快照。重复被在内部执行,因此对于客户端不可见。
目录操作的这样的重新开始可能使操作延时对于由许多不同客户端经常修改的目录相对大。因此,推荐客户端避免保持经常被并发修改的这样的目录。文件系统结构允许创建许多目录,并且因此更佳地是尽可能展开并发访问的结构、最多让目录仅由单个客户端修改。
(7.2.去除文件)
可以将HydraTFS中的文件的去除拆分成两个分离阶段。第一阶段是标记文件以用于去除。在这一操作之后,文件不再可见和可访问-它未作为目录条目对于客户端可见并且不能被打开。在内部,被标记以用于去除的文件仍然作为目录条目存在,但是它被放置于被标记以用于去除的子代的列表而不是存在的文件的列表上。
在下一小节中详细描述的第二阶段是在物理上去除文件,也就是说,标记构成文件的所有快照和标记器块以用于在HYDRAstor中删除。在目录的情况下,也去除所有子代,也就是说,目录去除是递归的。此后,可以从被标记以用于去除的子代的列表擦去条目。
在算法可以继续进入第二阶段、也就是标记快照以用于删除之前,必须保证无人使用待去除的文件。将简短地讨论相关机制。
第一阶段在实践中是由用户执行的去除文件操作。转而可以稍后在垃圾收集例程中执行第二阶段。
(7.3.去除标记的文件)
在标记文件以用于去除时,需要保证不再读取或者写入它。在坚果壳中,该机制是必须周期性地(定义周期为Th)刷新由客户端保持的文件句柄以保证句柄指向的文件仍然存在(也就是说,尚未被标记以用于去除)。如果文件被标记以用于去除,则客户端不再可以对它操作。为了保证未对文件操作,执行等待比文件句柄刷新周期更长的时段。等待持续时间被建立为2Th。
在保证不再对文件操作(即,读取或者写入)之后,可以执行尝试以去除它,也就是说,向它的存在的快照的所有快照根和所有标记器块写入删除根。在文件是目录的情况下,在将去除条目之前,也必须递归地去除所有子普通文件和目录。注意,即使不再读取或者写入文件,许多过程仍然可以并发地去除它。
在一开始,聚焦于标记给定的文件的所有快照和标记器块以用于删除的算法。然后,将继续描述在文件系统的范围中的去除过程。
(7.3.1.去除单个文件)
去除单个文件如同一般的去除例程可以由许多过程并发执行。另外,与HydraTFS的每个操作相似,可以在任何时间中断它。在这样的情形中,不容许HYDRAstor块泄漏。在另一方面,向不存在的留置根写入删除根和向留置根写入多个删除根是可允许的。
用于去除文件的方法在三个步骤中工作。首先,整个回收尾部被标记以用于删除。可以如正常的那样从在最新近快照的快照根中存储的回收尾部长度值取回回收尾部的长度。
当在HYDRAstor中标注整个回收尾部以用于删除时,留下的块是在通向最新近快照的路径上的标记器块,并且最新近快照本身也具有它的标记器块。第二步骤是标注最新近快照以用于删除。
在最后-第三-步骤中,与在第一步骤中标记回收尾部快照和标记器块以用于删除形成对照,在可以并行发出所有删除根写入请求时,现在需要标记用于删除的块的具体顺序。可以从最新近写入的(具有最高编号的)快照开始并且在快照编号1结束一个接一个地标记所有最新近快照的路径快照。
在图21中,图示了三个步骤。呈现的文件的最新近况快照具有编号26,并且回收尾部由快照19-23和25构成。在图21a中所示的第一步骤中,回收尾部被标记以用于删除:19、20、21、22、23、25。然后,在第二和第三步骤(图21b)中,最新近快照(26)以及然后的它的路径快照(24,16,8,4,2,1)被标记以用于删除。(图22:用于在文件去除期间删除快照的标记的顺序。)
“在去除期间崩溃”
去除文件的过程可以在以下执行步骤之一期间崩溃:
-在标记回收尾部以用于删除之时,
-在标记最新近快照以用于删除之时,
-在对标记器块进行标记以用于删除之时。
如果崩溃在第一步骤期间出现,则在重新开始之后计算相同回收尾部-基于在最新近快照中存储的回收尾部长度。因而,从开始重复步骤1而无损害。
在崩溃在成功写入指向最新近快照的删除根之前崩溃时,与步骤1相同的原理适用。因此,遗憾的是,在重新开始之后,必须不必要地重复整个步骤1。在崩溃转而在写入删除根之后出现时,在重新开始之后的该过程立即前进到步骤3。
在步骤3中,留下的仅有块是标记器块。由于块被标记以用于按照从在双二元搜索期间上一个拜访到第一个拜访的顺序删除,所以当在中间终端标记它们以用于删除时,双二元搜索将返回如下块,在该块之前,删除已经停止。因而,删除安全地重新开始。
请注意,获得最新近快照程序必须考虑存在已经被标记以用于删除的留置根(如它已经在小节2.4.4中被描述的那样)。在HYDRAstor在读取之时返回表示留置根已经被标记以用于删除的错误状态时,算法应当以与不存在的块相同的方式对待它。
“并发性”
多个过程可以并行执行标记单个文件的快照和标记器块以用于删除。在这样的情形中,它与在崩溃之后相似地工作。在通过执行获得最新近快照并且如果最新近快照仍然存在则从它读取回收尾部长度来确定将标记以用于删除的块集合之后,过程简单地按照指定的顺序写入删除根。仅有的缺点是可能向不存在的留置根或者向已经具有对应删除根(由并发过程写入)的留置根写入删除根。然而,在HYDRAstor中,它是可容许的行为。
(7.3.2.在文件系统级去除文件)
在文件系统的范围中去除文件实质上是如下操作,该操作对于给定的目录去除被标记以用于去除的所有子代。此后,从目录条目列表擦去去除的文件。可以在去除文件操作成功时触发或者在周期性文件系统扫描中执行这一操作。然而,优选两种方法的组合。利用触发,将快速去除被标记以用于去除的文件。整个文件系统的周期性扫描转而保证无去除的文件始终持续。这在过程标记文件以用于去除、但是在实际去除它们之前崩溃的情况下是可能的。
现在挖掘这一操作的细节。去除在目录中被标记以用于去除的文件工作如下:
1.读取目录条目。
2.将待去除的子代集合C初始化成目录的被标记以用于去除的子代的列表。
3.去除过程等待2Th以保证在C中的文件未被用户访问。
4.对于在C中的每个文件,(可能并行)完成在小节7.3.1中描述的快照的去除。
5.保证目录尚未被标记以用于去除或者同时被去除(如果它已经这样,则程序终止);这通过重新打开目录来执行。
6.再次读取目录-去除在C中包含的被标记以用于去除的子代的列表中的所有条目,并且事务地提交目录条目的新快照;重复该步骤直至提交成功。
在步骤5中执行的重新打开是必要的,因为目录可能已经同时被另一过程去除。在这样的情形中,提交目录的条目的新快照将引起提交的快照的泄漏。
在步骤4中去除的子代是目录而不是普通文件的情况下,在标记它的快照以用于删除之前,也必须去除包含的文件。因此,在可以标记目录的快照以用于删除之前执行以下步骤:
1.读取目录条目(另一实例可以已经标记目录的快照以用于删除(在这样的情况下,这一读取将不会成功,但是这不是问题),可以简单地转到标记目录的快照以用于删除),
2.对于每个子代c,无论是否存在或者被标记以用于去除,执行去除c;(另外,在c是目录的情况下,递归地执行这一操作)
<章节8>
(初步评估)
这一章节呈现用HydraTFS执行的实验的结果。在实验期间未完整地完成实现方式。重要事实是它缺乏对整个文件系统的性能具有主要影响的一些优化。然而,实验良好地反映HydraTFS在各种设置中的行为。
(8.1.实现方式)
(8.1.1.存在的特征)
在执行实验时,已经实施了核心功能的大部分。仅有的例外是标记快照以用于删除,这仍然在开发之中。因此,不能评估回收尾部删除和文件去除操作二者。尽管删除未操作,但是在小节6.3.3.中描述的标记器块已经存在。
然而,评估的实现方式遗漏一些主要优化。未在聚合的束中发送HYDRAstor请求。作为替代,接连处理它们,这显著减少性能,尤其是数据传输带宽。对于获得最新近快照操作,仅实施了在小节6.1中描述的线性算法。
(8.1.2.技术)
用C++开发实现方式。用具有最高优化级(-O3)的GCC编译器版本4.1.2编译在测试中使用的二进制文件。实现方式利用Boost库版本1.33.1。
已经在使用消息传递接口作为通信介质的多线程应用中实施了HydraTFS作为单线程模块。与HYDRAstor的通信由在相同应用的另一模块中实施的代理执行。两个模块、也就是代理模块和HydraTFS模块可以并行运行并且经由消息传递通信。在代理与HYDRAstor之间的通信经由被另一专用线程主控的网络套接字。
(8.2.测试环境)
实验设置由单个HYDRAstor装置构成,该HYDRAstor装置由一个访问节点和两个存储节点构成。每个节点具有两个四核64位3.0GHz Inter Xeon处理器。访问节点具有8GB存储器,并且存储节点各自为24GB。访问节点配备有使用硬件RAID的两个15K RPMSAS硬盘。这些盘用于在测试期间记录。所有计算机运行2.6.18-128Linux。
(8.3.实验)
在干净HYDRAstor系统上执行实验而未加载用户数据。无其他过程已经在测试期间使用HYDRAstor。
用随机数据填充向HYDRAstor保存的每个记录。这帮助最小化如下情形的数目,在这些情形中,具有相同数据的普通块已经在HYDRAstor中驻留。在这样的情况下,写入操作可以可能地由于可以使结果失真的去重复而显著更快地完成。
(8.3.1.向文件的记录追加的带宽)
在这一实验中,测量记录追加的带宽。在测试范例中的每个测试范例中创建包含128MB数据的单个普通文件。一系列写入在结束时跟随有单个提交。
在图22中呈现的范例在向文件系统写入的记录的大小上不同。然而,带宽差值并不显著,因为直至可以填充整个普通块才向HYDRAstor发送请求。换言之,作为影响带宽的主要因素的HYDRAstor请求的数量和大小在所有范例中相同。(图22:向文件的记录追加的带宽。)
值得注意的是,所得带宽(约6MB/s)与在HYDRAstor系统中的单个访问节点的在100MB/s以上的带宽比较很低。这应当在引入遗漏请求聚合(见小节8.1.1)之后提高。
(8.3.2.记录追加和提交的带宽)
这一实验与先前实验相似,但是在每个追加之后提交改变(执行提交文件)。在测试范例中的每个测试范例中创建包含8MB数据的单个普通文件。
如图23中可见,带宽与追加的记录的大小并且因而与提交操作的数目有关。记录越大,进行提交就越少。提交是高成本操作,因为它意味着等待HYDRAstor的所有与修改的文件的未决写入普通块请求。(图23:具有提交的记录追加的带宽。)
除此之外,可以向HYDRAstor多次写入一些数据。考虑小于最大普通块大小(64KB)的记录。在必须执行提交时,必须向HYDRAstor保存它。然而,在发出进一步追加时,一些数据(一个或者多个记录或者记录的一部分)可以与这一记录一起被放入块。然后,在发出另一提交时,在新普通块中再次向HYDRAstor写入相同记录。可以多次重复这样的情形直至用记录完整地填充块。
(8.3.3.读取的带宽)
在HydraTFS中,在打开普通文件之后,可以对文件执行读取。用户指定待立刻读取的记录的数目并且在它们的全部被读取时在单个答复中接收它们的内容。后继请求返回连续记录。也就是说,依次读取文件。一次在一个普通块内迭代快照的结构-未运用提前读取或者任何其他优化。在这一实验中,对于在单个请求中请求读取的记录的各种数目测量读取带宽。读取由各自为32kB的4096个记录以及单个快照构成的128MB文件。
结果示出带宽未随着请求大小的增加而显著改变。它在发送更大请求时略微增加,并且这与处理器使用率减少有关,该处理器使用率与HydraTFS请求的更低数目有关。然而,HYDRAstor普通块读取请求的数目保持相同。如同在追加的情况下,读取带宽应当在引入遗漏请求聚合之后提高。(图24:读取的带宽。)
(8.3.4.获得最新近快照的持续时间)
在这一实验中,测量获得最新近快照的时间。在测试范例中,创建具有快照序列的可变长度的文件。然后,执行在这样的文件中搜寻最新近快照的算法,并且已经测量了它的持续时间。对于在小节6.2中描述的双二元搜索算法,已经进行分析估计。在图25中示出结果。(图25:用于取回最新近快照的时间。)
在算法之间的不同在作为绝对值读取时不大。然而,它们可以变成更显著得多。在未被加载的系统上执行实验,并且HYDRAstor的留置根读取请求(主导操作)的延时为数十毫秒级。然而,它可以在系统被加载时显著增长。在这样的情形中,它可以超过一秒。
(8.3.5.对目录的操作的持续时间)
在这一实验中,已经在单个目录中创建了多个子目录。接连发出子目录创建请求。测试范例在创建的子目录的数目上不同(图26)。(图26:由单个线程执行的“创建目录”操作的时间。)
可以观察到,对于大量子目录,单个操作的平均时间相对更高。对于少量子目录,速度约为每秒10个操作,但是在创建2048个子目录时,它降至在2与3之间。它可以通过如下事实来说明,该事实为在目录条目的大小停止在单个留置根中相配时,创建子目录涉及到读取和写入更多块,因为在留置根指向的普通块中存储父目录的条目。在这样的情形中,HYDRAstor操作的数目增加(图27)。(图27:操作数目在树增长时增加-与平坦结构比较。)
(8.3.6.对目录的并行操作的持续时间)
在这一实验中涉及到多个过程。每个过程创建对于所有过程公共的一个目录的128个子目录。写入过程数目在测试范例之中变化(图28,“相同文件”)。(图28:比较“创建目录”操作的时间。)
这一实验示出向相同目录的并行写入访问的成本。增加访问过程数目意味着性能的显著减少。这由如下事实引起,该事实为由于并发访问而必须重新开始一些操作。因此,在HYDRAstor中的块操作数目增加(图29b)。
在另一实验中,对可变数目的目录操作-每个目录由一个过程操作(见图28,“不同文件”)。尽管与线程数目的增加有关的减速,但是对多个目录的操作的性能比在单个目录的情况下显著更高。
为了比较,在图28中示出如下估计,该估计呈现单个过程对相同数目的目录依次操作的时间。如可以预计的那样,单个线程对单个目录执行的操作数目比多个线程并行执行的相同数目的操作持续更短,因为无冲突存在,并且因此无需重新开始操作。
(8.3.7.打开在树中处于深处的目录)
在这一实验中,创建可变深度的目录结构。每个目录由一个快照构成,并且它的目录列表由零个条目(叶目录)或者一个条目(其余条目)构成。
在图30中示出页目录在给定它的路径时的取回(也就是,在"/level1Dir/level2Dir/.../levelNDir"上的打开文件操作)时间。可以看到,打开时间在文件在结构中处于更深处时增长。这是因为在这样的结构中,必须依次打开在通向目标目录的路径上的所有目录,也就是说,首先是“/”、然后是“level1Dir”、“level2Dir”并且以此类推。
虽然打开可能消耗时间,但是对在这样的深度位置的目录或者普通文件的其他操作的性能与位于别处的目录并无不同。这是因为在打开之后,每个文件被它的文件ID引用,并且无需读取它的父目录中的任何父目录以取回或者更新它的内容。
<章节9>
(有关工作)
(91.1.HydraFS)
Hydra文件系统“HFS”与HydraTFS相似地在HYDRAstor上面运行。在这些文件系统之间的主要不同是设计目标。HydraFS是以高读取/写入流性能为目标的文件系统,因为它的主要应用是备份装置的一部分。另外,它提供典型Unix文件系统接口,并且因此可以被自由地用作标准、通用文件系统。对照而言,HydraFS作为应用的模块工作。
其他根本不同是一次仅从一个访问节点访问HydraFS。对照而言,可以一次从所有访问节点访问HydraTFS。HydraFS的持久布局被构造作为具有由留置根代表的根(即超块)的单个树。超块指向按照i节点编号排序的i节点映射结构的根,该i节点映射结构包含所有文件和目录。
每个节点映射条目转而指向构成单个文件的树。这一个树与在HydraTFS中的单个快照的树相似。这一架构使容易预备整个文件系统的快照变得容易-保存文件系统树的留置根而不是在它变成过时时删除它就足够了。由于必须激进地高速缓存树的块以便实现令人满意的性能,并且由于向文件的写入涉及到修改树中的在直至根的路径上的所有块,所以HydraFS可能在对多个文件同时操作时性能欠佳。转而,在HydraTFS的情况下,文件是独立的,并且对不同文件的操作未在任何级干扰。
排除HydraFS作为用于HydraTFS的备选的重要原因是如下事实,该事实为HydraFS不能存储HYDRAstor内容地址-仅允许原始数据字节。除此之外,它不是事务的,因此使用HydraFS将需要引入附加层,例如,数据库。最后,由于HydraFS一次从单个AN可访问,所以将需要在这一访问节点与其他访问节点之间的连接。在HydraTFS中无这样的要求。
(9.2.其他解决方案)
已经创建了若干存在的文件系统以便实现高可用性。Ivy“Ivy”是分散式对等文件系统。向文件系统写入数据的每个用户(置于分布式哈希表各处)保持他的修改的日志。所有参与者扫描其他参与者的日志并且向他们的私有快照施加改变。在网络分区的情况下,文件系统的多个版本可以出现。在这样的情形中,可以运用外部冲突化解器。
Ceph“Ceph”文件系统完全分散而无单个故障点。无缝地复制数据,这使它容错。在盘故障的情况下,复制物被用来向其他盘分发数据直至重新获得目标冗余性。Google Chubby“Chubby”是分布式锁定服务,该锁定服务提供与文件系统的接口相似的接口。小文件总是作为整体被读取和写入。它在Google主要用来应对从等效机器的集合选择首领的问题并且作为用于小元数据的高度地可用位置。Google File System和Bigtable是利用Chubby的系统的明显示例。在它的实现方式中,Chubby使用与Berkeley DB“BerkDB”的复制版本相似的解决方案。数据库日志借助分布式合意协议分布于协议之中。
用各种方式实现在文件系统中的数据和元数据一致性,并且外部工具是常见解决方案。例如,Lustre“Lustre”这一种以大群集为目标的大规模并行文件系统使用分布式锁定管理器以保护文件数据和元数据的完整性。
事务NTFS(缩写为TxF)“TxF”是在Windows系统中的部件,该部件引入对NTFS文件系统的事务操作。它使用名为内核事务管理器“KTM”的部件-在Windows内核模式中操作的通用事务引擎。
实施与HydraTFS的快照相似的想法的文件系统的示例是Elephant“Elephant”。Elephant自动保持和维护选择的有价值文件的旧版本。在写入模式中的每个打开操作时创建打开的文件的新版本。对应的关闭操作转而对版本定稿。不同于HydraTFS,Elephant提供对旧文件版本的访问;事实上,这是它的核心功能之一。可以在旧文件版本变得过时时根据各种策略立即或者将来删除它们。特别地,可以存储所有文件版本从而提供文件的完全修改历史。
文件系统后台清理在专用于闪存驱动的文件系统中是常见的。例如,在JFFS2“JFFS2”中,它在块级出现。引入垃圾收集器以便聚合对特定块的I/O操作并且因此减少这样的操作的数目。这对于闪存的磨损调平是必需的。
除了HFS之外,存在为CAS块存储库设计的其他文件系统。Centera“Centera”这一种以企业市场为目标的CAS提供文件系统接口。然而,本地存储文件系统的元数据,并且向CAS进行它的周期性备份。在Venti“Venti”中,从未删除块。因此,在低频率产生文件系统的快照以免耗尽存储装置。
(9.3.结论)
枚举的文件系统都不可以取代HydraTFS来使用。这是因为请求的文件系统必需在HYDRAstor上面运行,因为需要存储内容地址。有问题的是存在的文件系统中的任何文件系统是否已经成功地通过端口接到HYDRAstor。然而,即使有可能,这样的过程仍将可能需要比设计和实施新文件系统远远更多的工作从而满足要求。
<章节10>
(结论)
已经将在本文中呈现的HydraTFS设计作为在无需在客户端节点之间的任何附加网络通信的CAS系统上工作的分散式、事务和可伸缩文件系统。实验结果示出HydraTFS满足设计目标并且以合理性能工作。然而,可以在许多方面中显著地优化它。
可以使用在本文中包括的考虑和想法作为用于进一步优化HydraTFS的起点。另外,它们可以在开发在除了HYDRAstor之外的内容可寻址存储装置上面工作的具有相似特征的文件系统期间有帮助。当前在商用HYDRAstor产品中集成HydraTFS。
<补充备注>
可以将以上公开的示例性实施例的全部或者部分描述作为以下补充备注。以下将描述根据本发明的一种存储系统(参照图31)、程序和信息处理方法的概况。然而,本发明不限于以下配置。
<补充备注1>
一种存储系统100,包括:
数据写入装置111,用于向存储设备120中存储配置待写入的存储数据的实际数据,并且每当存储数据的内容被更新时,向存储设备120中新存储被配置更新的存储数据的实际数据;以及
数据指定装置112,用于指定在存储设备120中存储的相同存储数据之中的最新存储数据,其中:
数据写入装置111被配置用于与每当存储数据被更新时其值增加1的更新信息关联地向存储设备120中存储配置存储数据的实际数据;并且
数据指定装置112被配置用于按照i(i代表等于或者大于0的整数)的值的增加顺序检查值为2i的更新信息是否存在于存储设备120中,从存在的更新信息存在的2i的最大值与2i+1的值之间的值之中指定对应的更新信息的最大值,并且指定由与更新信息的最大值关联的实际数据配置的存储数据作为最新存储数据。
<补充备注2>
根据补充备注1的存储系统,其中数据指定装置被配置用于:
设置对应的更新信息在存储设备中存在的2i的最大值作为第一更新信息,并且还设置2i+1的值作为第二更新信息;
执行更新信息搜索过程,更新信息搜索过程检查与在第一更新信息与第二更新信息之间的中间值对应的更新信息是否存在于存储设备中;
执行中间值替换过程,中间值替换过程在与中间值对应的更新信息存在于存储设备中时设置中间值作为第一更新信息,而在与中间值对应的更新信息未存在于存储设备中时设置中间值作为第二更新信息;并且
通过反复地执行更新信息搜索过程和中间替换过程来指定在存储设备中存在的更新信息的最大值。
<补充备注3>
根据补充备注2的存储系统,包括:数据删除装置,用于从存储设备删除配置不是最新的存储数据的实际数据和与实际数据关联的更新信息,其中:
数据指定装置被配置用于指定已经在指定更新信息的最大值时被搜索并且与在存储设备中存在的2i的值对应的更新信息作为非删除目标更新信息;并且
数据删除装置被配置用于从将被从存储设备删除的信息排除被指定作为非删除目标更新信息的更新信息。
<补充备注4>
根据补充备注3的存储系统,其中数据指定装置被配置用于指定如下更新信息作为非删除目标更新信息:已经在指定更新信息的最大值时被搜索的并且与在存储设备中存在的2i的值对应的更新信息、与所述中间值对应的更新信息,以及被指定的最大值的更新信息。
<补充备注5>
根据补充备注3或者4的存储系统,其中数据指定装置被配置用于在由与比在存储设备中存在的更新信息的最大值更小的值的更新信息关联的实际数据配置的存储数据正被访问时,在非删除目标更新信息中包括访问目标更新信息以及在数据指定装置将访问目标更新信息指定作为更新信息的最大值时被搜索并且被指定作为非删除目标信息的更新信息,访问目标更新信息是与配置被访问的存储数据的实际数据关联的更新信息。
<补充备注6>
根据补充备注5的存储系统,其中数据指定装置被配置用于在非删除目标信息中包括其值比在存储设备中存在的更新信息的最大值更小并且比访问目标更新信息的值更大的更新信息。
<补充备注7>
根据补充备注3至6中的任一补充备注的存储系统,其中数据删除装置被配置用于从存储设备删除与被指定作为非删除目标更新信息的更新信息关联的实际数据。
<补充备注8>
根据补充备注1至7中的任一补充备注的存储系统,其中数据写入装置被配置用于与指定相同存储数据的数据指定信息关联地存储更新信息。
<补充备注9>
根据补充备注8的存储系统,其中数据写入装置被配置用于:
将存储数据划分成多个实际数据并且向存储设备中存储,并且还存储引用实际数据的相应引用数据和可由多个引用数据访问的数据指定信息,多个引用数据引用配置存储数据的多个实际数据;
在存储数据更新时,在存储具有与已经被存储在存储设备中的实际数据相同的内容的其他实际数据时,存储其他实际数据以便通过使用引用已经在存储设备中存储的实际数据的引用数据来引用已经被存储在存储设备中的实际数据作为其他实际数据,而在存储未被存储在存储设备中的实际数据时,向存储设备中新存储实际数据;并且
每当存储数据被更新时,新生成可由多个引用数据访问的数据指定信息,多个引用数据引用配置被更新的存储数据的多个实际数据。
<补充备注10>
一种包括用于使信息处理设备实现以下装置的指令的程序:
数据写入装置,用于向存储设备中存储配置待写入的存储数据的实际数据,并且每当存储数据的内容被更新时,向存储设备中新存储配置更新的存储数据的实际数据;以及
数据指定装置,用于指定在存储设备中存储的相同存储数据之中的最新存储数据,其中:
数据写入装置被配置用于与每当存储数据被更新时其值增加1的更新信息关联地向存储设备中存储配置存储数据的实际数据;并且
数据指定装置被配置用于按照i(i代表等于或者大于0的整数)的值的增加顺序检查其值为2i的更新信息是否存在于存储设备中,从存在的更新信息存在的2i的最大值与2i+1的值之间的值之中指定对应的更新信息的最大值,并且指定由与更新信息的最大值关联的实际数据配置的存储数据作为最新存储数据。
<补充备注11>
根据补充备注10的程序,其中数据指定装置被配置用于:
设置对应的更新信息在存储设备中存在的2i的最大值作为第一更新信息,并且还设置2i+1的值作为第二更新信息;
执行更新信息搜索过程,更新信息搜索过程检查与在第一更新信息与第二更新信息之间的中间值对应的更新信息是否存在于存储设备中;
执行中间值替换过程,中间值替换过程在与中间值对应的更新信息存在于存储设备中时设置中间值作为第一更新信息,而在与中间值对应的更新信息未存在于存储设备中时设置中间值作为第二更新信息;并且
通过反复地执行更新信息搜索过程和中间替换过程来指定在存储设备中存在的更新信息的最大值。
<补充备注12>
根据补充备注11的程序,还包括用于使信息处理设备实现以下装置的指令:数据删除装置,用于从存储设备删除配置不是最新的存储数据的实际数据和与实际数据关联的更新信息,其中:
数据指定装置被配置用于指定已经在指定更新信息的最大值时被搜索并且与在存储设备中存在的2i的值对应的更新信息作为非删除目标更新信息;并且
数据删除装置被配置用于从将被从存储设备删除的信息排除被指定作为非删除目标更新信息的更新信息。
<补充备注13>
根据补充备注12的程序,其中数据指定装置被配置用于指定如下更新信息作为非删除目标更新信息:已经在指定更新信息的最大值时被搜索并且与在存储设备中存在的2i的值对应的更新信息、与所述中间值对应的更新信息,以及被指定的最大值的更新信息。
<补充备注14>
一种信息处理方法,包括:
向存储设备中存储配置待写入的存储数据的实际数据,并且每当存储数据的内容被更新时向存储设备中新存储配置被更新的存储数据的实际数据并且写入数据,并且在这时,与每当存储数据被更新时其值增加1的更新信息关联地向存储设备中存储配置存储数据的实际数据;并且
在指定在存储设备中存储的相同存储数据之中的最新存储数据时,按照i(i代表等于或者大于0的整数)的值的增加顺序检查其值为2i的更新信息是否存在于存储设备中,从存在的更新信息存在的2i的最大值与2i+1的值之间的值之中指定对应的更新信息的最大值,并且指定由与更新信息的最大值关联的实际数据配置的存储数据作为最新存储数据。
<补充备注15>
根据补充备注14的信息处理方法,包括在指定最新数据时包括:
设置对应的更新信息在存储设备中存在的2i的最大值作为第一更新信息,并且还设置2i+1的值作为第二更新信息;
执行更新信息搜索过程,更新信息搜索过程检查与在第一更新信息与第二更新信息之间的中间值对应的更新信息是否存在于存储设备中;
执行中间值替换过程,中间值替换过程在与中间值对应的更新信息存在于存储设备中时设置中间值作为第一更新信息,而在与中间值对应的更新信息未存在于存储设备中时设置中间值作为第二更新信息;并且
通过反复地执行更新信息搜索过程和中间替换过程来指定在存储设备中存在的更新信息的最大值。
<补充备注16>
根据补充备注15的信息处理方法,包括:
在指定最新数据时,指定已经在指定更新信息的最大值时被搜索并且与在存储设备中存在的2i的值对应的更新信息作为非删除目标更新信息;并且
在从存储设备删除配置不是最新的存储数据的实际数据和与实际数据关联的更新信息时,从将被从存储设备删除的信息排除被指定作为非删除目标更新信息的更新信息。
<补充备注17>
根据补充备注16的信息处理方法,包括:
在指定最新数据时,指定如下更新信息作为非删除目标更新信息:已经在指定更新信息的最大值时被搜索并且与在存储设备中存在的2i的值对应的更新信息、与所述中间值对应的所述更新信息,以及被指定的最大值的更新信息。
上述程序被存储于存储设备中或者被记录于计算机可读记录介质上。例如,记录介质是便携介质,比如软盘、光盘、磁光盘和半导体存储器。
虽然以上已经参照示例性实施例和补充备注描述了本发明,但是本发明并不限于上述示例性实施例。可以在本发明的范围内用本领域技术人员可以理解的各种方式变更本发明的配置和细节。
标号描述
1 存储系统
2 加速器节点
3 存储节点
4 备份系统
5 备份目标设备
11 数据写入部分
12 数据取回部分
13 数据指定部分
14 数据删除部分
20 存储设备
30 应用
100 存储系统
111 数据写入装置
112 数据指定装置
120 存储设备
Claims (17)
1.一种存储系统,包括:
数据写入装置,用于向存储设备中存储配置待写入的存储数据的实际数据,并且每当所述存储数据的内容被更新时,向所述存储设备中新存储配置被更新的所述存储数据的实际数据;以及
数据指定装置,用于指定在所述存储设备中存储的相同存储数据之中的最新存储数据,其中:
所述数据写入装置被配置用于与每当所述存储数据被更新时其值增加1的更新信息关联地向所述存储设备中存储配置所述存储数据的实际数据;并且
所述数据指定装置被配置用于按照i(i代表等于或者大于0的整数)的值的增加顺序来检查其值为2i的所述更新信息是否存在于所述存储设备中,从存在的所述更新信息存在的2i的最大值与2i+1的值之间的值之中指定对应的所述更新信息的最大值,并且指定由与所述更新信息的所述最大值关联的实际数据配置的存储数据作为所述最新存储数据。
2.根据权利要求1所述的存储系统,其中所述数据指定装置被配置用于:
设置对应的所述更新信息在所述存储设备中存在的2i的所述最大值作为第一更新信息,并且还设置2i+1的所述值作为第二更新信息;
执行更新信息搜索过程,所述更新信息搜索过程检查与所述第一更新信息与所述第二更新信息之间的中间值对应的所述更新信息是否存在于所述存储设备中;
执行中间值替换过程,所述中间值替换过程在与所述中间值对应的所述更新信息存在于所述存储设备中时设置所述中间值作为所述第一更新信息,而在与所述中间值对应的所述更新信息未存在于所述存储设备中时设置所述中间值作为所述第二更新信息;并且
通过反复地执行所述更新信息搜索过程和所述中间替换过程来指定在所述存储设备中存在的所述更新信息的所述最大值。
3.根据权利要求2所述的存储系统,包括:数据删除装置,用于从所述存储设备删除配置不是最新的所述存储数据的所述实际数据和与所述实际数据关联的所述更新信息,其中:
所述数据指定装置被配置用于指定已经在指定所述更新信息的所述最大值时被搜索、并且与在所述存储设备中存在的2i的所述值对应的所述更新信息作为非删除目标更新信息;并且
所述数据删除装置被配置用于从将被从所述存储设备删除的信息排除被指定作为所述非删除目标更新信息的所述更新信息。
4.根据权利要求3所述的存储系统,其中所述数据指定装置被配置用于指定如下更新信息作为所述非删除目标更新信息:已经在指定所述更新信息的所述最大值时被搜索并且与在所述存储设备中存在的2i的所述值对应的所述更新信息、与所述中间值对应的所述更新信息,以及被指定的所述最大值的所述更新信息。
5.根据权利要求3或者4所述的存储系统,其中所述数据指定装置被配置用于在由与比在所述存储设备中存在的所述更新信息的所述最大值更小的值的所述更新信息关联的所述实际数据配置的存储数据正被访问时,在所述非删除目标更新信息中包括访问目标更新信息以及在所述数据指定装置将所述访问目标更新信息指定为所述更新信息的所述最大值时被搜索并且被指定作为所述非删除目标信息的所述更新信息,所述访问目标更新信息是与配置被访问的所述存储数据的所述实际数据关联的所述更新信息。
6.根据权利要求5所述的存储系统,其中所述数据指定装置被配置用于在所述非删除目标信息中包括其值比在所述存储设备中存在的所述更新信息的所述最大值更小、并且比所述访问目标更新信息的值更大的所述更新信息。
7.根据权利要求3至6中的任一权利要求所述的存储系统,其中所述数据删除装置被配置用于从所述存储设备删除与被指定作为所述非删除目标更新信息的所述更新信息关联的所述实际数据。
8.根据权利要求1至7中的任一权利要求所述的存储系统,其中所述数据写入装置被配置用于与指定所述相同存储数据的数据指定信息关联地存储所述更新信息。
9.根据权利要求8所述的存储系统,其中所述数据写入装置被配置用于:
将所述存储数据划分成多个实际数据并且向所述存储设备中存储,并且还存储引用所述实际数据的相应引用数据和可由所述多个引用数据访问的所述数据指定信息,所述多个引用数据引用配置所述存储数据的所述多个实际数据;
在所述存储数据更新时,在存储具有与已经被存储在所述存储设备中的实际数据相同的内容的其他实际数据时,存储所述其他实际数据,以便通过使用引用已经在所述存储设备中存储的所述实际数据的所述引用数据来引用已经被存储在所述存储设备中的所述实际数据作为所述其他实际数据,而在存储未被存储在所述存储设备中的实际数据时,向所述存储设备中新存储所述实际数据;并且
每当所述存储数据被更新时,新生成可由所述多个引用数据访问的所述数据指定信息,所述多个引用数据引用配置被更新的所述存储数据的所述多个实际数据。
10.一种包括用于使信息处理设备实现以下装置的指令的程序:
数据写入装置,用于向存储设备中存储配置待写入的存储数据的实际数据,并且每当所述存储数据的内容被更新时,向所述存储设备中新存储配置被更新的所述存储数据的实际数据;以及
数据指定装置,用于指定在所述存储设备中存储的相同存储数据之中的最新存储数据,其中:
所述数据写入装置被配置用于与每当所述存储数据被更新时其值增加1的更新信息关联地向所述存储设备中存储配置所述存储数据的实际数据;并且
所述数据指定装置被配置用于按照i(i代表等于或者大于0的整数)的值的增加顺序检查其值为2i的所述更新信息是否存在于所述存储设备中,从存在的所述更新信息存在的2i的最大值与2i+1的值之间的值之中指定对应的所述更新信息的最大值,并且指定由与所述更新信息的所述最大值关联的实际数据配置的存储数据作为所述最新存储数据。
11.根据权利要求10所述的程序,其中所述数据指定装置被配置用于:
设置对应的所述更新信息在所述存储设备中存在的2i的所述最大值作为第一更新信息,并且还设置2i+1的所述值作为第二更新信息;
执行更新信息搜索过程,所述更新信息搜索过程检查与所述第一更新信息和所述第二更新信息之间的中间值对应的所述更新信息是否存在于所述存储设备中;
执行中间值替换过程,所述中间值替换过程在与所述中间值对应的所述更新信息存在于所述存储设备中时设置所述中间值作为所述第一更新信息,而在与所述中间值对应的所述更新信息未存在于所述存储设备中时设置所述中间值作为所述第二更新信息;并且
通过反复地执行所述更新信息搜索过程和所述中间替换过程来指定在所述存储设备中存在的所述更新信息的所述最大值。
12.根据权利要求11所述的程序,还包括用于使所述信息处理设备实现以下装置的指令:数据删除装置,用于从所述存储设备删除配置不是最新的所述存储数据的所述实际数据和与所述实际数据关联的所述更新信息,其中:
所述数据指定装置被配置用于指定已经在指定所述更新信息的所述最大值时被搜索、并且与在所述存储设备中存在的2i的所述值对应的所述更新信息作为非删除目标更新信息;并且
所述数据删除装置被配置用于从将被从所述存储设备删除的信息排除被指定作为所述非删除目标更新信息的所述更新信息。
13.根据权利要求12所述的程序,其中所述数据指定装置被配置用于指定如下更新信息作为所述非删除目标更新信息:已经在指定所述更新信息的所述最大值时被搜索并且与在所述存储设备中存在的2i的所述值对应的所述更新信息、与所述中间值对应的所述更新信息,以及被指定的所述最大值的所述更新信息。
14.一种信息处理方法,包括:
向存储设备中存储配置待写入的存储数据的实际数据,并且每当所述存储数据的内容被更新时向所述存储设备中新存储配置被更新的所述存储数据的实际数据并且写入所述数据,并且在这时,与每当所述存储数据被更新时其值增加1的更新信息关联地向所述存储设备中存储配置所述存储数据的实际数据;并且
在指定在所述存储设备中存储的相同存储数据之中的最新存储数据时,按照i(i代表等于或者大于0的整数)的值的增加顺序检查其值为2i的所述更新信息是否存在于所述存储设备中,从存在的所述更新信息存在的2i的最大值与2i+1的值之间的值之中指定对应的所述更新信息的最大值,并且指定由与所述更新信息的所述最大值关联的实际数据配置的存储数据作为所述最新存储数据。
15.根据权利要求14所述的信息处理方法,包括在指定所述最新数据时:
设置对应的所述更新信息在所述存储设备中存在的2i的所述最大值作为第一更新信息,并且还设置2i+1的所述值作为第二更新信息;
执行更新信息搜索过程,所述更新信息搜索过程检查与在所述第一更新信息和所述第二更新信息之间的中间值对应的所述更新信息是否存在于所述存储设备中;
执行中间值替换过程,所述中间值替换过程在与所述中间值对应的所述更新信息存在于所述存储设备中时设置所述中间值作为所述第一更新信息,而在与所述中间值对应的所述更新信息未存在于所述存储设备中时设置所述中间值作为所述第二更新信息;并且
通过反复地执行所述更新信息搜索过程和所述中间替换过程来指定在所述存储设备中存在的所述更新信息的所述最大值。
16.根据权利要求15所述的信息处理方法,包括:
在指定所述最新数据时,指定已经在指定所述更新信息的所述最大值时被搜索、并且与在所述存储设备中存在的2i的所述值对应的所述更新信息作为非删除目标更新信息;并且
在从所述存储设备删除配置不是最新的所述存储数据的所述实际数据和与所述实际数据关联的所述更新信息时,从将被从所述存储设备删除的信息排除被指定作为所述非删除目标更新信息的所述更新信息。
17.根据权利要求16所述的信息处理方法,包括:
在指定所述最新数据时,指定如下更新信息作为所述非删除目标更新信息:已经在指定所述更新信息的所述最大值时被搜索并且与在所述存储设备中存在的2i的所述值对应的所述更新信息、与所述中间值对应的所述更新信息,以及被指定的所述最大值的所述更新信息。
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US201161531966P | 2011-09-07 | 2011-09-07 | |
US61/531,966 | 2011-09-07 | ||
PCT/JP2012/005549 WO2013035295A1 (en) | 2011-09-07 | 2012-09-03 | Storage system |
Publications (2)
Publication Number | Publication Date |
---|---|
CN103765393A true CN103765393A (zh) | 2014-04-30 |
CN103765393B CN103765393B (zh) | 2016-12-07 |
Family
ID=47831767
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201280043434.9A Active CN103765393B (zh) | 2011-09-07 | 2012-09-03 | 存储系统 |
Country Status (5)
Country | Link |
---|---|
US (1) | US9665304B2 (zh) |
EP (1) | EP2754053A4 (zh) |
JP (1) | JP5500309B2 (zh) |
CN (1) | CN103765393B (zh) |
WO (1) | WO2013035295A1 (zh) |
Cited By (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN106662981A (zh) * | 2014-06-27 | 2017-05-10 | 日本电气株式会社 | 存储设备、程序和信息处理方法 |
CN108287912A (zh) * | 2018-02-06 | 2018-07-17 | 广东暨通信息发展有限公司 | 一种大数据存储系统 |
CN109901792A (zh) * | 2017-12-08 | 2019-06-18 | 爱思开海力士有限公司 | 存储器系统及其操作方法 |
CN113383318A (zh) * | 2019-02-05 | 2021-09-10 | 微软技术许可有限责任公司 | 减少垃圾回收标记中的同步依赖 |
CN117130980A (zh) * | 2023-10-24 | 2023-11-28 | 杭州优云科技有限公司 | 一种虚拟机快照管理方法及装置 |
Families Citing this family (43)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US9223790B1 (en) * | 2011-08-31 | 2015-12-29 | Amazon Technologies, Inc. | Managing deletion of data in a data storage system |
WO2013102506A2 (en) | 2012-01-02 | 2013-07-11 | International Business Machines Corporation | Method and system for backup and recovery |
US9052824B2 (en) | 2012-01-26 | 2015-06-09 | Upthere, Inc. | Content addressable stores based on sibling groups |
US9183212B2 (en) * | 2012-01-26 | 2015-11-10 | Upthere, Inc. | Representing directory structure in content-addressable storage systems |
US9172670B1 (en) * | 2012-01-31 | 2015-10-27 | Google Inc. | Disaster-proof event data processing |
US9208082B1 (en) * | 2012-03-23 | 2015-12-08 | David R. Cheriton | Hardware-supported per-process metadata tags |
US9356939B1 (en) * | 2013-03-14 | 2016-05-31 | Ca, Inc. | System and method for dynamic access control based on individual and community usage patterns |
US9659023B2 (en) | 2013-11-21 | 2017-05-23 | Upthere, Inc. | Maintaining and using a cache of child-to-parent mappings in a content-addressable storage system |
US9092376B1 (en) | 2014-08-29 | 2015-07-28 | Nimble Storage, Inc. | Methods and systems for ordering virtual machine snapshots |
CN106663052A (zh) * | 2014-09-11 | 2017-05-10 | 株式会社东芝 | 文件系统、数据重复排除方法以及用于文件系统的程序 |
WO2016043757A1 (en) * | 2014-09-18 | 2016-03-24 | Hewlett Packard Enterprise Development Lp | Data to be backed up in a backup system |
US10496313B2 (en) | 2014-09-22 | 2019-12-03 | Hewlett Packard Enterprise Development Lp | Identification of content-defined chunk boundaries |
US9778990B2 (en) | 2014-10-08 | 2017-10-03 | Hewlett Packard Enterprise Development Lp | Methods and systems for concurrently taking snapshots of a plurality of virtual machines |
WO2016072996A1 (en) | 2014-11-06 | 2016-05-12 | Hewlett Packard Enterprise Development Lp | Network policy graphs |
US9727252B2 (en) * | 2014-11-13 | 2017-08-08 | Hewlett Packard Enterprise Development Lp | Methods and systems for optimal snapshot distribution within a protection schedule |
US10621143B2 (en) * | 2015-02-06 | 2020-04-14 | Ashish Govind Khurange | Methods and systems of a dedupe file-system garbage collection |
JP6229684B2 (ja) * | 2015-03-19 | 2017-11-15 | 日本電気株式会社 | ストレージ装置、ストレージ制御方法、及びストレージ制御プログラム |
US10296219B2 (en) | 2015-05-28 | 2019-05-21 | Vmware, Inc. | Data deduplication in a block-based storage system |
US10120893B1 (en) * | 2015-09-17 | 2018-11-06 | Amazon Technologies, Inc. | Storing data to content-addressable storage |
US11157517B2 (en) * | 2016-04-18 | 2021-10-26 | Amazon Technologies, Inc. | Versioned hierarchical data structures in a distributed data store |
WO2017182063A1 (en) | 2016-04-19 | 2017-10-26 | Huawei Technologies Co., Ltd. | Vector processing for segmentation hash values calculation |
WO2017182062A1 (en) | 2016-04-19 | 2017-10-26 | Huawei Technologies Co., Ltd. | Concurrent segmentation using vector processing |
US11726979B2 (en) | 2016-09-13 | 2023-08-15 | Oracle International Corporation | Determining a chronological order of transactions executed in relation to an object stored in a storage system |
US10733159B2 (en) | 2016-09-14 | 2020-08-04 | Oracle International Corporation | Maintaining immutable data and mutable metadata in a storage system |
US10216417B2 (en) | 2016-10-26 | 2019-02-26 | Samsung Electronics Co., Ltd. | Method of consolidate data streams for multi-stream enabled SSDs |
US10860534B2 (en) * | 2016-10-27 | 2020-12-08 | Oracle International Corporation | Executing a conditional command on an object stored in a storage system |
US10169081B2 (en) | 2016-10-31 | 2019-01-01 | Oracle International Corporation | Use of concurrent time bucket generations for scalable scheduling of operations in a computer system |
US10180863B2 (en) | 2016-10-31 | 2019-01-15 | Oracle International Corporation | Determining system information based on object mutation events |
US10956051B2 (en) | 2016-10-31 | 2021-03-23 | Oracle International Corporation | Data-packed storage containers for streamlined access and migration |
US10552372B2 (en) * | 2017-01-31 | 2020-02-04 | Microsoft Technology Licensing, Llc | Systems, methods, and computer-readable media for a fast snapshot of application data in storage |
US10860550B1 (en) | 2017-03-30 | 2020-12-08 | Amazon Technologies, Inc. | Versioning schemas for hierarchical data structures |
US10671639B1 (en) | 2017-03-30 | 2020-06-02 | Amazon Technologies, Inc. | Selectively replicating changes to hierarchial data structures |
US10698808B2 (en) | 2017-04-25 | 2020-06-30 | Samsung Electronics Co., Ltd. | Garbage collection—automatic data placement |
US11048624B2 (en) | 2017-04-25 | 2021-06-29 | Samsung Electronics Co., Ltd. | Methods for multi-stream garbage collection |
US11010401B2 (en) * | 2017-04-25 | 2021-05-18 | Microsoft Technology Licensing, Llc | Efficient snapshot generation of data tables |
US20180314957A1 (en) * | 2017-04-28 | 2018-11-01 | Hewlett Packard Enterprise Development Lp | Inferring a label namespace |
US10812342B2 (en) | 2017-04-28 | 2020-10-20 | Hewlett Packard Enterprise Development Lp | Generating composite network policy |
US10176046B1 (en) * | 2017-06-29 | 2019-01-08 | EMC IP Holding Company LLC | Checkpointing of metadata into user data area of a content addressable storage system |
US10691666B1 (en) * | 2017-08-23 | 2020-06-23 | CloudBD, LLC | Providing strong consistency for object storage |
CN110609807B (zh) * | 2018-06-15 | 2023-06-23 | 伊姆西Ip控股有限责任公司 | 用于删除快照数据的方法、设备和计算机可读存储介质 |
US11392541B2 (en) * | 2019-03-22 | 2022-07-19 | Hewlett Packard Enterprise Development Lp | Data transfer using snapshot differencing from edge system to core system |
US12019873B2 (en) * | 2022-07-28 | 2024-06-25 | Netapp, Inc. | Methods and systems to improve resumption time of input/output (I/O) operations based on prefetching of configuration data and early abort of conflicting workflows during a non-disruptive automatic unplanned failover from a primary copy of data at a primary storage system to a mirror copy of the data at a cross-site secondary storage system |
US20240143453A1 (en) | 2022-10-28 | 2024-05-02 | Netapp, Inc. | Methods and systems to reduce latency of input/output (i/o) operations during creation of common snapshots based on batching of synchronous replicated datasets at a primary storage system to a cross-site secondary storage system |
Family Cites Families (14)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5778368A (en) * | 1996-05-03 | 1998-07-07 | Telogy Networks, Inc. | Real-time embedded software respository with attribute searching apparatus and method |
US7836029B2 (en) * | 2003-07-08 | 2010-11-16 | Pillar Data Systems, Inc. | Systems and methods of searching for and determining modified blocks in a file system |
US7756844B2 (en) * | 2003-07-08 | 2010-07-13 | Pillar Data Systems, Inc. | Methods of determining and searching for modified blocks in a file system |
US7444389B2 (en) | 2003-12-09 | 2008-10-28 | Emc Corporation | Methods and apparatus for generating a content address to indicate data units written to a storage system proximate in time |
US7225371B2 (en) * | 2004-08-03 | 2007-05-29 | International Business Machines Corporation | Method and apparatus for storing and retrieving multiple point-in-time consistent data sets |
EP1966699A2 (en) * | 2005-12-22 | 2008-09-10 | Nxp B.V. | Memory with block-erasable locations and a linked chain of pointers to locate blocks with pointer information |
US8412682B2 (en) * | 2006-06-29 | 2013-04-02 | Netapp, Inc. | System and method for retrieving and using block fingerprints for data deduplication |
US7849057B1 (en) * | 2007-03-30 | 2010-12-07 | Netapp, Inc. | Identifying snapshot membership for blocks based on snapid |
JP5084551B2 (ja) | 2008-02-26 | 2012-11-28 | Kddi株式会社 | 重複排除技術を用いたデータバックアップ方法、記憶制御通信装置及びプログラム |
JP5320557B2 (ja) * | 2008-03-25 | 2013-10-23 | 株式会社日立製作所 | ストレージシステム |
US7567188B1 (en) * | 2008-04-10 | 2009-07-28 | International Business Machines Corporation | Policy based tiered data deduplication strategy |
US7992037B2 (en) * | 2008-09-11 | 2011-08-02 | Nec Laboratories America, Inc. | Scalable secondary storage systems and methods |
US8335889B2 (en) * | 2008-09-11 | 2012-12-18 | Nec Laboratories America, Inc. | Content addressable storage systems and methods employing searchable blocks |
US8412688B1 (en) * | 2009-06-29 | 2013-04-02 | Emc Corporation | Delegated reference count base file versioning |
-
2012
- 2012-09-03 EP EP12829663.9A patent/EP2754053A4/en not_active Ceased
- 2012-09-03 CN CN201280043434.9A patent/CN103765393B/zh active Active
- 2012-09-03 US US13/818,226 patent/US9665304B2/en active Active
- 2012-09-03 JP JP2013506369A patent/JP5500309B2/ja active Active
- 2012-09-03 WO PCT/JP2012/005549 patent/WO2013035295A1/en active Application Filing
Cited By (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN106662981A (zh) * | 2014-06-27 | 2017-05-10 | 日本电气株式会社 | 存储设备、程序和信息处理方法 |
CN106662981B (zh) * | 2014-06-27 | 2021-01-26 | 日本电气株式会社 | 存储设备、程序和信息处理方法 |
CN109901792A (zh) * | 2017-12-08 | 2019-06-18 | 爱思开海力士有限公司 | 存储器系统及其操作方法 |
CN108287912A (zh) * | 2018-02-06 | 2018-07-17 | 广东暨通信息发展有限公司 | 一种大数据存储系统 |
CN113383318A (zh) * | 2019-02-05 | 2021-09-10 | 微软技术许可有限责任公司 | 减少垃圾回收标记中的同步依赖 |
CN117130980A (zh) * | 2023-10-24 | 2023-11-28 | 杭州优云科技有限公司 | 一种虚拟机快照管理方法及装置 |
CN117130980B (zh) * | 2023-10-24 | 2024-02-27 | 杭州优云科技有限公司 | 一种虚拟机快照管理方法及装置 |
Also Published As
Publication number | Publication date |
---|---|
US9665304B2 (en) | 2017-05-30 |
WO2013035295A1 (en) | 2013-03-14 |
CN103765393B (zh) | 2016-12-07 |
EP2754053A4 (en) | 2015-12-23 |
JP5500309B2 (ja) | 2014-05-21 |
JP2013543601A (ja) | 2013-12-05 |
US20140189270A1 (en) | 2014-07-03 |
EP2754053A1 (en) | 2014-07-16 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN103765393B (zh) | 存储系统 | |
KR102579190B1 (ko) | 일관된 데이터베이스 스냅샷들을 이용한 분산 데이터베이스에서의 백업 및 복원 | |
US11210220B2 (en) | Log-structured storage for data access | |
US10146643B2 (en) | Database recovery and index rebuilds | |
CN1746893B (zh) | 事务文件系统 | |
US9811522B2 (en) | System and method for transforming a source virtual machine without copying of payload data | |
US8250033B1 (en) | Replication of a data set using differential snapshots | |
US7650341B1 (en) | Data backup/recovery | |
US10565070B2 (en) | Systems and methods for recovery of consistent database indexes | |
US7395278B2 (en) | Transaction consistent copy-on-write database | |
US7433902B2 (en) | Non-disruptive backup copy in a database online reorganization environment | |
US11847028B2 (en) | Efficient export of snapshot changes in a storage system | |
CN103460197A (zh) | 计算机系统、文件管理方法以及元数据服务器 | |
US9619322B2 (en) | Erasure-coding extents in an append-only storage system | |
Strzelczak et al. | Concurrent Deletion in a Distributed {Content-Addressable} Storage System with Global Deduplication | |
Shaull et al. | Skippy: a new snapshot indexing method for time travel in the storage manager | |
Sinnamohideen et al. | A {Transparently-Scalable} Metadata Service for the Ursa Minor Storage System | |
US20230244649A1 (en) | Skip-List Checkpoint Creation | |
US11269837B2 (en) | Data tree checkpoint and restoration system and method | |
Appuswamy | Building a File-Based Storage Stack: Modularity and Flexibility in Loris | |
Gupta | RSnap: resursive writable snapshots for logical volumes |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
C14 | Grant of patent or utility model | ||
GR01 | Patent grant |