本科生毕业设计(论文)外文翻译《云存储的版本控制备份和同步》_第1页
本科生毕业设计(论文)外文翻译《云存储的版本控制备份和同步》_第2页
本科生毕业设计(论文)外文翻译《云存储的版本控制备份和同步》_第3页
本科生毕业设计(论文)外文翻译《云存储的版本控制备份和同步》_第4页
本科生毕业设计(论文)外文翻译《云存储的版本控制备份和同步》_第5页
已阅读5页,还剩23页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

XX理工大学本科生毕业设计(论文)外文翻译I本科生毕业设计(论文)外文翻译外文原文题目:VersionedFileBackupandSynchronizationforStorageCloud中文翻译题目:云存储的版本控制备份和同步姓名:XXX学院:软件学院班级:XXXXXX指导教师:XXXTOC\o"1-6"\h\z\u第1章 简介 1第2章 相关的工作 3第3章 设计 53.1 RosyCloud的数据对象 53.2 Dir 53.3 Snapshot 63.4 FileObject 63.5 Backup 73.6 Synchronization 83.7 文件共享 113.8 讨论 11第4章 实现 134.1 概述 134.2 公用功能 144.3 优化 15第5章 评价 165.1 基准 165.2 存储使用 175.1 时间花费 185.2 金钱花费 19第6章 结论和未来的工作 21摘要云存储已被广泛应用于数据备份和归档。当前归档系统通常支持特定的云服务,这种供应商绑定问题在供应商停止提供云服务时就会引起数据迁移甚至数据丢失的挑战。我们建议用一个RosyCloud系统来对不同的云的数据进行自动备份和同步。RosyCloud是用一个http请求的云存储接口来保持云上所有加密文件的版本,并支持不同的设备异步与云同步。由同步造成的冲突可以用DAG模型来检测并解决。RosyCloud也支持不同用户间安全的文件共享。我们已经实现了三个主流云存储的RosyCloud原型。实验表明RosyCloud能在低成本的情况下搞高效的实现云备份和云同步。PAGE 简介 云存储服务吸引了许多机构和个人把他们的数据在云中[24,5,25]。与本地驱动器相比,云存储提供了更高的效用—能力,无限的空间,更低的成本。在特定的云存储上存储数据很方便,但也是脆弱的。依赖于特定的协议和云供应商的工具可能会使未来的迁移成本昂贵和困难。Megaupload[2的关闭显示尽管服务提供商可以保证五99.999可用性,但是仍然有一种可能性,如果用户的一部分数据蒸发,用户可能仍然失去他们有价值的数字资产。 以前的工作[5]已解决供应商锁定通过在多个云上分配数据和重点是数据备份。然而,典型的用户往往不仅需要备份数据,而且还需要与云同步的设备数据。现有的工具如Dropbox[1]使它可以同步数据不同的设备,但有相同的供应商锁定问题。因此,需要有一个工具,备份数据多个存储云,支持同步对于不同的设备。做这样一个工具是具有挑战性的。存储云不具有执行用户代码的能力,并且只能使用缺乏原子的标准接口访问操作.因此,很难从多个异步设备同步写入,除非用复杂的锁定协议[5]。锁定的问题是持有锁的装置阻止其他的设备写,这延会迟备份和同步操作。考虑到设备可能会不时从云中断开,这个问题可能变得更糟。 我们提出了RosyCloud,它支持不同的云和终端设备的文件备份和同步的版本控制。具体来说,RosyCloud的将不同版本的文件备份在多个云,避免供应商锁定并提供高可用性的文件。文件可以更新,同时,所有的修改都会被版本化,而设备和云之间的同步是周期性的执行,并且会基于有向无环图(DAG)模型进行自动冲突检测和分辨率。为了保护用户数据不受到网络攻击和行为不端的云的影响,Rosycloud加密所有数据的云存储,提供不同用户之间的安全文件共享。我们已经实现了—个支持三个主流云存储服务的Rosycloud原型。实验结果表明,成本非常低,并且RosyCloud可以有效的备份和同步典型办公工作负荷的数据。 这项工作的贡献包括:1)自动使用存储云的同步机制和无服务器计算要求的接口2)基于DAG的快照依赖冲突检测模型。 本文的其余部分组织如下。美国证券交易委员会—总结相关工作。第三节给出了设计RosyCloud和第四部分提出了实施。第五节评价RosyCloud的表现。最后,第六节总结未来工作。

相关的工作 备份是一种被广泛接受的做法,以防止数据丢失[18,8,27]。云计算的进展使得云存储成为一个理想的数据备份和存档介质。Cumulus[24]实现备份系统超过AMA—ZONS3[3]云存储,用一个薄云的假设。为了提高服务的可用性,在多个云上备份正在被研究[6,25]。Rosycloud不仅具有 文件备份,也可以在多个设备上同步文件,这还没有先例。 Depsky[5]是一个通用的备份系统云存储作为后端。DepSky是以版本号来保存文件的。一系列的Byzantinequorum协议是用于实现单写、多读数据模型。支持多个写者,一个复杂的文件锁定协议用于序列化并发写操作。相比Depsky,RosyCloud的同步更有效,因为RosyCloud使用内容的散列来实现版本,而不是版本号,以避免昂贵写同步。文件同步可以用集中的方式成功地实现。大多数源控制系统,例如,SCCS[16][4],CVS,Subversion,Perforce[17],[29],以这种方法,其中集中式服务器确保同步—被访问的文件库,使用版本号标记不同的更新。如果服务器崩溃或断开连接,所有客户都访问不了文件库。为了解决集中式存储库的问题,许多分布式版本控制系统已经开发[14,30]用户保存库的本地副本和可以将本地副本与其他用户或其他服务器同步。我们的工作灵感来自这些分布式版本控制系统。类似pastwatch[30],在RosyCloud中修订历史被组织成一个树和并且写—写冲突可以被检测和解决。不同的是在rosycloud模型,云存储服务器被动的,他们只提供基本的文件访问并不提供任何额外的计算要求。这拓宽了RosyCloud在不同公共云服务市场的可用性。但没有服务器计算能力,确保自动更新变得更加困难[5],我们必须依靠客户端执行通用版本控制操作,如散列,差异或比较。商业产品如Dropbox[1]提供文件在多个设备上进行备份、共享和同步跨越不同的用户。这些产品使用专用云存储用户数据并有专用服务器的存储[26]。相比之下,RosyCloud的目的是支持不同存储云使用薄接口和不强加服务器计算需求。本设计避免了供应商绑定问题。然而,没有专用服务器部署在云方面,RosyCloud需要执行额外的设备的计算和同步逻辑。最后,分布式文件系统[11,19,9,22,23,21)提供设备透明的、可扩展的文件存储系统界面。在这个意义上,RosyCloud不同于他们通过驻留在较低水平的存储堆栈(更多接近块设备),并提供有限的文件集操作.因此,RosyCloud可以在没有集中式元数据的完全分布式范例服务器上实现。Coda[21]支持断开文件修改并检测写入写入冲突,这是提交给用户来用于解决此问题的。相比之下,RosyCloud用一个DAG来解决冲突。

设计在RosyCloud,用户可以在每个设备上设置一个目录,然后RosyCloud就可以将数据备份到多个云的目录中,并在这些设备之间同步数据。云存储所有版本的文件,而设备只有一个用户文件的快照。 Rosycloud假定云存储服务暴光一个小的基于HTTP的接口: •store:创建一个新对象;•remove:删除对象;•retrieve:读取一个对象的内容;•list:返回一个对象标识符列表。本节的其余部分首先讨论了数据模型RosyCloud,然后提出了备份和同步程序。最后,讨论了文件共享。RosyCloud的数据对象在RosyCloud中云端的所有数据均以对象存储,对象可以分为元数据对象和文件对象。每个对象都由一个32字节的字符串索引,object内容编码成10进制128位的MD5散列。在实践中这个哈希冲突的概率小到足以被忽略。有三种类型的对象:元数据对象,即,目录(Dir),快照(Snapshot)和文件对象(fileobjects)。如下。Dir一个Dir对象代表着通常文件系统中的一个物理目录,它包含一个文件目录条目的list,我们称之为DirEntry。Dir中的每一个DirEntry代表一个文件或是一个目录,并且包含所有的必需的隐含的文件/目录描述信息。表I总结了RosyCloud中一个DirEntry结构中的所有元数据字段。模式字段指示是否Mode字段表示对象是文件或目录。如果此条目指向一个文件,Size字段记录文件的大小。否则,条目将指向另一个Dir对象在Size字段中为零。Name代表在云上使用的云文件名,这是10进制128位的MD5散列。FileName是终端设备上的文件或目名。EncryptionKey字段是用于加密相应的对象,这是一个随机生成的128位密钥以增加安全性。密钥存储在DirEntry对象中,它们通过父母密钥递归加密可在目录遍历中检索。本设计消除了存储所有加密密钥的需求,这可能会变得相当大和需要昂贵的费用来维护大量的密钥。Snapshot一个快照对象表示文件在特定的时间的系统状态,可以以后回复。一旦创建,快照是不可变的。任何文件系统的更改导致新快照,它将以前的快照作为父对象。图1说明了快照对象的内容。快照对象包含一个DirEntry结构指示根目录。为了检测与解决冲突,快照应该能够在文件系统的修订历史中定位自己。所以从父快照(当前快照是从当前快照派生的)引用也包含在快照对象中。而且,一些标志可以与快照关联。快照的演变形成一个DAG,就像第III-C)中讨论的那样。图中多sink节点的存在,更新冲突可能存在。RosyCloud尝试解决这样的冲突。FileObjectRosyCloud中的文件是作为一个独立的对象在每个云中存储的。以前的工作[24,25]组织文件成块和聚集小文件变大部分.但是,维护文件的块对于备份恢复和文件同步效率不高。这是因为一个文件的块可以扩展到许多段,这意味着检索文件数据可能需要提取多个段,可能浪费时间和带宽。因此,rosycloud选择不使用内部数据块作为基本备份单元,也不聚合小文件。BackupRosycloud自动将文件备份到所有的存储云.具体而言,一个存储云被用户指定为主体,将接收所有用户备份和存储所有快照。没有这个主体,版本DAG一个云可能会错过一些快照,造成同步问题.通常,主云在比其他更新更频繁。用户可选择备份所有快照的所有存储云具有相同的频率,但是这样会增加备份延迟和成本。RosyCloud不需要用户保持连接云存储。用户可以自由地决定何时设置设备脱机和何时成为联机。在离线时间,本地文件系统的所有修改记录会被日志记录。一旦连接到云在稍后的时间,这些变化将与云中的数据同步。备份是由文件系统变化通知驱动的[15,13],这在大多数现代操作系统是可用的。当通知被解除,RosyCloud过滤器写事件并将更改后的文件上载到云端。rosycloud更新云对象创建一个新的对象但是旧对象不变。当本地文件系统通知修改,整个对象将被上传到云而不是增量更新差异[16,17,24]。虽然昂贵的意义上,甚至一字节修改将导致整个文件被上传,此更新策略简化恢复和回滚。鉴于一个版本在特定的时间,对象可以在没有跟踪快照历史和应用补丁—接一个的情况下恢复。图2说明了快照之间的数据依赖关系,包括目录和文件对象快照。矩形和圆分别代表目录和文件。快照1拍摄是在之前拍摄的,是快照2的父亲。快照1包含一个根目录和两个文件,file1和file2,驻留在dir1,root的子目录。在稍后的一段时间,file2被更新,文件的新版本被创建.因此,一个新版本的dir1目录对象也创建.快照2包含更新的根目录和新的文件对象以及未修改的引用文件夹快照1包含一个根目录和两个文件,file1和file2,驻留在dir1,root的子目录。在稍后的一段时间,file2被更新,文件的新版本被创建.因此,一个新版本的dir1目录对象也创建.快照2包含更新的根目录和新的文件对象以及未修改的引用文件夹.一个新版本的dir1目录对象也创建.快照2包含更新的根目录和新的文件对象以及未修改的引用文件夹.SynchronizationRosyCloud保持定时器来周期性地同步本地文件和主存储云系统。因为设备和主存储云之间的备份和同步是异步的,冲突可能发生和表现作为快照中的DAG。我们讨论冲突是如何检测并描述如何自动合并冲突。1)冲突检测:当使用多个终端设备时,文件冲突很容易发生,因为用户编辑一个设备上的文件时可能不知道从其他设备也在同时对同一文件进行修改。当设备与云存储同步时,检测是否存在冲突,所有已采取的快照遍历构造快照的依赖DAG。在这个图中,每个节点代表一个快照和一个从父级表示数据派生关系快照到子快照。如果只有一个汇聚节点在这个DAG中,这个节点代表了最新版本一致的图像。如果存在多个汇聚节点,然后这些接收器节点代表冲突的快照和我们讨论短期决议。图STYLEREF1\s图STYLEREF1\s3SEQ图\*ARABIC\s11Rosycloud更新在云端存储每一次修改发生.圆角矩形,正方形和圆圈分别代表快照,目录和文件对象。阴影表示新创建的对象。两个快照之间的箭头表示派生依赖关系DAG。这主要是因为那里最近的快照没有云端引用。即使有这样一个文件包含引用,有没有原子操作来更新文件,并且复杂的锁定协议是必需的[5]。然而,当使用锁,持有锁的设备将防止其他设备从并发写入到云存储,影响性能。相反,我们对于不可更改的快照和冲突的后期解决的方法使并发写成为可能。2)冲突解决:两个相互冲突的快照nx和ny在合并过程中创建一个新节点伪依赖边分别为nx和ny。这个新节点表示在nx和ny对象之间解决冲突后的快照。为了弄清楚对象是否应该留在代表合并结果的新节点中,我们计算快照DAG(依赖于nx和n的DAG)中的最小共同祖先(LCA)。LCA需要作为参考点,以确定哪些对象是从LCA更新到nx或ny,这利用了快照中文件对象关系。然后从两个冲突快照的根目录开始,递归递归执行目录层次融合。如果快照DAG有两个以上的汇聚节点,则冲突解决的合并过程首先选择两个具有最小哈希值的快照,将这两个快照合并为一个新的节点在DAG,并继续直到所有冲突快照合并。最后,当所有冲突的快照合并后,将合并的快照上载到云端。图3说明了合并过程的示例。最初,快照A包含文件A和O,快照B通过删除A生成,快照C通过O改为O’生成。显然,B和C是冲突的快照。然而,只有这两个快照,我们无法确定是否在B中删除A或创建在C中,O和O’哪个是最新的。注意我们不能依靠时间戳来确定哪一个是新的太,因为两个设备的时钟可能不同步。这些问题可以很容易地解决,如果我们知道一个是在这个例子中的B和C的LCA,因为一个出现在A和C,我们知道A在B中被删除。可以确定O是在C.修改的结果,合并快照只包含O’,如果两个已更改文件快照是不相交的,那么这两个快照是静静的使用已更改的文件版本合并。例如,如果两在不同的文件上执行写入,然后它们可以安全地合并。如果两个写入应用于同一文件,然后用户干预是必要的,除非写入更改相同。一般来说,合并过程中有两种情况需要人工检查: •写-写冲突发生时,不同的变化发生在同一文件。•写-删除冲突发生时,一个快照删除文件时,而另一个在修改同一文件。对于上述两个相互冲突的情况,两个版本的文件保持和一个版本更名为用户的图图STYLEREF1\s3SEQ图\*ARABIC\s12一个解决合并冲突的范例进一步检验等。专门用于写写冲突,一个版本的有更小的散列值的文件需要改变前缀即文件名加上“MODIFY-CONFLICT-”。写删除冲突,从LCA移除的版本被重命名为前缀“DELETE-CONFLICT-”。因为很多种可能存在冲突的快照,前缀还包括文件散列以相互区分。目录冲突与文件冲突不同。因为合并从根目录开始,一个目录的写-写冲突可以是一个文件写-写冲突的,或一个子目录冲突,或是将递归合并的,或文件和子文件目录的名字冲突.在最后一个案例中,冲突文件被重命名。对于写-删除类型的目录冲突,已删除目录要被重命名。3)设备之间的同步:在RosyCloud,设备之间不直接同步文件。相反,每个设备上传局部变到主云并定期与主云同步获得从其他设备文件的修改。因此,同一文件的修改从一个设备可以通过主云存储传播到另一个设备。文件共享图STYLEREF1\s3图STYLEREF1\s3SEQ图\*ARABIC\s13两个用户之间共享文件涉及五个步骤。箭指示快照派生。快照使得RosyCloud的文件共享很方便。每个对象在一个云是由一个随机的128位AES密钥加密。我们假设每个用户都有一对安全的公钥和私钥并且用户有一个安全的方式验证公钥。图4说明了文件共享的五个步骤。1)当请求文件时,鲍伯发送他的公共密钥给亚当。2)亚当收到请求后,收集要分享的所有文件到一个新的快照和并用一个带有随机键k加密快照。3)加密快照上载到云端。4)亚当发送鲍伯的快照URL和用鲍伯的公共密钥加密后的键K。5)鲍勃解密密钥K和访问快照,用K解密快照,并可获得共享文件。讨论 所有用户的设备通常主存储云与备份和同步。如果主变得无法访问(例如,不再存在),RosyCloud可能会失去一些快照。然而,在其他存储云的副本存在所有最新的文件都存储在终端设备上。在用户决定新的主存储云后,所有快照后将将存储在新的主存储云和不同的设备将再同步。因为新的主可能包含不完整的快照,第一次设备同步新的主可能导致出现被删除的文件和一些冲突。然而,这一次没有最新的文件丢失。 一个可能的问题是,当同步进程更新本地文件时,用户可能会主动编辑文件,导致写写冲突。对于这种类型的冲突,RosyCloud推迟了该文件的更新直到下一个同步轮,即等待文件被关闭再同步。

实现我们在Linux上实现了一个基于Python平台的rosycloud原型。目前,RosyCloud支持三种存储云、AlibabaAliyun的OSS1、WindowsAzure2,和GoogleDrive3.因为RosyCloud只使用最小的存储接口,很容易支持这三种云。概述在RosyCloud中的数据沿着两个不同事件驱动的非对称方向流动。本地文件系统更改的通知事件启动数据备份到云端。定时器事件触发周期性本地设备和存储云之间的同步。RosyCloud中的模块:•更改通知捕获系统的本地设备文件的修改事件,然后启动备份修改文件到不同的云。我们使用Linuxinotify[15]API监视文件系统的变化。因为许多inotify事件不改变文件,RosyCloud仅响应表2中列出的写事件。这个备份时间刚好在每个修改中一个可调的时间间隔设置,在一个小的间隔减少冲突的机会,但增加了传输到云上的数据量。•装饰器上传到云端之前执行数据压缩和加密。因此,只有云存储保存装饰数据,即压缩和加密数据。目前,我们使用bzip2压缩数据和每个文件,加密使用AES算法与随机128位密钥。•定时器定时触发同步。RosyCloud检查云端上来自从其他终端设备更新是否可用,并下载对应的对象。•冲突解析器检测并解决更新冲突。反装饰器执行与装饰器相反的功能,以明文形式计算原始数据,并图图STYLEREF1\s4SEQ图\*ARABIC\s11通知事件图然后将数据保存在磁盘上。 图STYLEREF1\s图STYLEREF1\s4SEQ图\*ARABIC\s12rosycloud的功能公用功能RosyCloud提供了一些和方便的公用功能,总结在表三中。实用版本列出存储在云中的对象的所有可用版本。实用Tag将快照标识符与备忘录关联在一起,而不是一个32字节的哈希值。另一个实用程序,xtarct,提取有版本控制的文件到本地文件系统。最后,grant和share帮助在不同用户之间共享文件。grant负责授予和撤销访问特权,share从其他用户下载共享文件到本地磁盘。优化为了减少带宽的使用,所有的元数据对象,即Dir和快照对象,都会在本地缓存,因为它们在构建快照DAG与重构文件系统结构时将被集中引用。因为同步进行周期性和快照DAG构造每一次,每个设备也缓存DAG结构,只更新DAG与新的快照对象。为了减少网络流量,我们只在它被关闭时上传一个文件到云,而不是每次写时调用。对于临时文件,如编辑时的交换文件RosyCloud允许用户定义的一组规则忽视他们的改变。

评价 我们评价RosyCloud的表现来回答以下的问题:•RosyCloud空间的开销是多少?•RosyCloud花费多少时间备份,恢复,设备之间的同步?•当使用多个云时RosyCloud的花费? 图STYLEREF1\s图STYLEREF1\s5SEQ图\*ARABIC\s11内存占用图基准在我们的评价中使用了两个基准来评估RosyCloud,办公室工作量跟踪和邮件服务器的工作量从filebench产生[28]。第一个办公室工作负荷跟踪是从本文作者的桌面电脑,持续一个周。在此期间,所有系统调用作者的家目录被记录。主目录的总大小是约15GB。因为用户专注于一个项目在当时,只有一小部分文件是积极的更新。过滤掉没有更改的目录后,最初的活动文件约222.3MB。统计此活动文件集如表IV所示,其中文件较少超过4KB被归类为小,那些大于1MB被认定为大。中小型更新大小文件占主导地位的工作量。大部分的修改在文本文件上执行。一些二进制文件可以被创建为中间文件,并最终将从文件中删除系统或改名[10]。图STYLEREF1\s图STYLEREF1\s5SEQ图\*ARABIC\s12工作曲线图基准[12]。邮件服务器工作量大多个小文件,在模式中创建,书写,读取,最后删除文件。存储使用本实验研究了云的存储使用。图6云存储对云存储的变化工作量.最初,压缩数据大小在云中是34.33MB。随着时间的推移,云存储在使用逐渐增加,这是预期的副本—写入更新模型。在跟踪结束时,总数据大小是345.6MB,这是大于大小为230.7MB本地设备上。这是因为云存储保持所有修改文件的版本。图6还显示了总大小快照对象,发展稳定的时间只有消耗一小部分云存储。这是因为快照对象只包含元数据信息。图7说明了邮件服务器的存储更改工作量,运行filebench[28]十分钟。因为工作量是由一系列的文件创建,读取和删除操作,本地存储仍然保持平。然而,云存储线性增图图STYLEREF1\s5SEQ图\*ARABIC\s13rosycloud在邮件服务器上的曲线图加,因为删除的文件被保存为云中的一个版本。正如我们所看到的立即采取快照确实增加云存储要求。用户可以通过以下方式限制快照的数量扩大备份时间间隔控制和减少存储要求。如图所示,当我们增加备份时间间隔为20秒,云存储空间可以节省。如果备份每一分钟,甚至节省更多空间。类似办公室工作量情况(如图所示,快照消耗很少的存储空间。时间花费1)备份与恢复时间:本实验研究备份和恢复操作的时间成本。这个备份开始是用一个空的云,RosyCloud将处理后的数据传送到云存储。恢复反转备份过程,其中本地文件系统是空的,所有数据都是从云中同步的,模仿空端的初始同步设备。 我们比较四种不同的备份存储介质:另一种同一机器上的硬盘,千兆字节上的NFS共享兰,阿里云的操作系统,和WindowsAzure。OSS是本地的云存储提供商,它比WindowsAzure具有更好的网络性能。图8说明了这四种方法的时间成本随着办公室工作量。使用另一个磁盘和NFS执行最好的,因为从源磁盘到目的地存储的低延迟。由于更好的网络连接,OSS比Windows性能更好Azure。所有四方法,完全还原时间小于备份。OSS和WindowsAzure,原因是写云储存慢于读。因为写必须成功的多副本的写[7],它需要更多的时间比读,因为读可以在任何一个副本成功时返回一定的时间。对于本地磁盘和NFS,时间差是由于不同的从磁盘读取数据量。备份操作需要读取222.3MB,而恢复只读只有34.3MB压缩数据。2)同步时间:本实验测量使用办公室同步不同设备的时间工作量.在实验中,家里的笔记本电脑与办公室的台式机通过OSS同步。笔记本电脑设置为与OSS同步每十五分钟。这个累积分布函数(CDF)的时间是经过文件更新到办公室的台式机到文件同步到笔记本,如图9所示。所有文件在原始文件更新之后18分钟内同步,并且平均延迟为8.6分钟。因为用户从家里到办公室需要大约20分钟,系统始终能够在用户到达之前同步文件,允用户继续做剩下的工作。金钱花费云存储不是一个“免费午餐”,我们研究使用rosycloud办公室图STYLEREF1\s图STYLEREF1\s5SEQ图\*ARABIC\s14花费图图图STYLEREF1\s5SEQ图\*ARABIC\s15云空间花费图

结论和未来的工作本文介绍了RosyCloud的设计,实施和评估,它是一个版本控制的文件备份和同具,拥有HTTP接口。RosyCloud支持并行文件更新通过复制写快照。从不同的设备写的冲突可以通过DAG依赖模型检测和解决。据我们所知,这是第一个没有服务器计算要求的支持多云环境的备份和同步工具。我们的评估显示,RosyCloud是灵活的支持不同的云,并且花费合理的时间与低成本。RosyCloud未来的工作包括使用纠删码,将文件内容分发到不同的云以节约存储空间与成本。另一种减少云存储使用的方法是垃圾收集存储在云上的未使用的快照。为此,我们计划实施不同的基于时间和重要性的快照回收方法[20]。

特此鸣谢我们要感谢XX和所有的匿名评论者的真知灼见。这工作是—部分由国家自然科学基金(补助金XXXXX和XXXXX)和XXX中国计划(批准XXXXXX)支持。X是由美国国家科学基金会的支持XXXXXXX。任何意见,调查结果、结论或建议材料是作者的,不一定反映这些赞助商的意见。

引用[1]Dropbox。/.[2]Megaupload文件共享网站关闭。http:www.bbc.co.uk/news/technology-16642369,2012。[3]亚马逊网络服务。亚马逊简单存储服务。/s3/.[4]B.Berliner。CVSII:并行软件开发。在Proc。冬天的USENIX会议,1990。[5]A.Bessani,M.Correia,B.Quaresma,F.André,andP.Sousa。Depsky:云上可靠和安全的存储。第六届计算机系统大会上,第31-46页。ACM,2011。[6]C.Cachin,R.Haas,M.Vukolic。可靠的云存储。研究报告RZ,3783:1–6,2010.。[7]B.Calder,J.Wang,A.Ogus,N.Nilakantan,A.Skjolsvold,S.McKelvie,Y.Xu,S.Srivastav,J.Wu,H.Simitci,等。Windowsazurestorage:高一致性,高可用的云存储服务.在三分之二十ACM程序中操作系统原理研讨会,页143-157。ACM,2011。[8]L.Cox,C.Murray和B.Noble。拼贴:使备份便宜和容易。ACMsigops操作系统评论,36(SI):285-298,2002。[9]H.Gobioff,S.LeungS.Ghemawat。谷歌文件系统。在ACMsigops操作系统评论,第37卷,第29页-43。ACM,2003。[10]T.Harter,C.Dragga,M.Vaughn,A.C.Arpaci-Dusseau,andR.H.Arpaci-Dusseau。文件不是文件:理解苹果桌面的I/O行为应用.在三分之二ACM程序中操作系原理研讨会,SOSP11,第71页-83,纽约,NY,美国,2011。ACM。[11]J.H.Howard,M.L.Kazar,S.G.Menees,D.A.Nichols,M.Satyanarayanan,R.N.Sidebotham,andM.J.West.。分布式文件系统的规模和性能。计算机系统交易(TOC),6(1):51–81,1988。[12]J.Katcher.Postmark:一个新的文件系统基准。技术报告,技术报告tr3022网络应用,1997。www.netapp.com/techlibrary/3022.html,1997。[13]J.Lemonm.Kqueue:一个通用的和可扩展的事件通知机制。在USENIX会议技术freenix跟踪年度会议141-153页,2001。[14]J.Loeliger。版本控制与Git。O'ReillyMedia,2009。[15]R.Love.Kernelkorner:Introtoinotify:介绍inotify。Linux杂志,2005(139):8,2005。[16]J.Marc。源代码控制系统。IEEE软件工程交易。SE-1(4),页364–470,1975。[17]C.Pilato

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论