[FAST 2009]Cumulus:File System Backup to the Cloud

这篇文章来自于加州大学圣迭戈分校的, 这家伙发的文章遍布OSDI，SOSP和FAST等会议，感兴趣的童鞋可以去它的链接里看看。

文章的idea很清晰，我尝试着把它说出来看看：

当前的云存储服务按照提供商对某种特别服务的“包装”的层次不同，分为两个极端：

1.Thin-Cloud（薄云）:只提供了一些简单但是功能强大的接口，用户可以根据这些接口，自己花费精力，用客户端去实现一些有针对性的服务，例如文件备份（本文的焦点）。


2.Thick-Cloud（厚云）:云存储提供商对某些服务已经进行了包装和整合，将一些已经做好的服务直接提供给用户去使用。

薄云的优点是：
      A ）可以在多个提供商之间进行比较方便的切换，例如：你自己实现的这一套文件备份系统如果在A厂商的云存储上使用的不爽了，你就可以换呗，最多把它提供的接口改一下。
      B ）便宜，文章中专门有对价钱的评估，由于本人孤陋寡闻，暂时不知道当前在国内有没有提供这类接口的商家。
      C ）透明，因为高层服务是你自己包装的，不会被“捆绑销售”。

至于厚云的优点呢，正好和薄云相反：

A) 不用自己开发一套专业用途的系统，省事。
B) 服务的性能是根据厂商自己底层的存储服务器而量身定做的，因此，更加能够保持性能的可接受性。
C) 服务不会耗费用户端或者客户端的机器的资源，这和薄云相反，因为在薄云中，你必须在本地实现一些额外的功能，这些功能，是由你本地机器提供的。


本篇文章致力于在这两者之间“插一脚",并且用一个实际的系统Cumulus来论述它的这个可以”插一脚“的方法的合理性以及可投机取巧性（后面会详谈）。

利用Amonzon's EC2/S3(笔者暂时对这个东西不是很了解)提供的四个接口，作者开发出了一个本地文件备份系统Cumulus，可以把本地的文件，通过网络，上传到云端；当文件系统需要恢复时，就从云端拿回来，这四个接口是：

1）Get:  可以从服务器获得某个文件的内容。
2) Put:  从本地上传一个文件至服务器。
3) List: 在服务器上把所有原来上传的文件罗列出来。
4) Delete:在服务器上删除某个指定的文件，以节省空间，因为云存储服务器上要按照你上传空间的多少来收取费用。

Cumulus系统存在以下几个亮点：
1. 把一些小文件进行合并，多个小文件合并成一个Segment（段）。
这样做的原因是：
A）小文件会造成存储系统的内部碎片以及过多的元数据，引起不必要的空间浪费，导致用户多出钱；

B）文件越少，在用户端和服务端传递的网络开销也就越少；

C）更有利于文件之间的去冗余（我是这样理解的，一个Segment里的小文件之间可能存在多个相同的子部分，有利于缩小"这几个小文件的总大小之和"，以节约空间）

D) 顺便提供了一层加密信息（因为几个小文件变成了一个文件，原来的语义信息或多或少得到了一层蒙蔽）

E）更有利于文件的增量的表示(这样想，A文件当中的一小部分得到修改后，我用另外一个文件A’来表示A文件改变的部分；如果一个Segment当中的某个小文件得到了修改，我可以很方便的把其他没有得到修改的小文件表示出来)。

2.文件快照（Snapshot）的表现形式。

至于这一点，作者也只是在描述其实现的方法，没有太多吸引人的东西，感兴趣的读者可以下文章自己看。

3.文件的增量

4.无用的Segment的清理
如果一个segment当中，被最近的快照使用的部分如果没有超过一个阈值a%，该segment则会成为cleaning的对象，当然，a部分还是会保留，1-a的部分会被删除，回收空间。

以上的2，3点感觉都是一篇文章凑字数的很boring的部分，估计读者和评审都不会花太多功夫去看。

至于实现部分，作者采用了一问一答的方式来设计实验，给人的感觉很清爽。

相信大家都已经猜到了，实验的结果就是性能比起”厚云“来说，有过之而无不及，价格，更加便宜，一切看起来都是那么完美，那么和谐。

总结
文章的精髓在于作者提出了在”厚云“和”薄云“之间的”做手脚“的思想，提醒了咱们天朝的子民，如果有厂商在我们这片富饶的土地上提供了一些更加便宜的”麻烦“接口，我们可以利用其接口，克服其麻烦，开发出一些脍炙人口的服务，以稍微贵一点的价格，卖给最终用户，以实现社会的共同富裕。

至于系统，本人觉得倒是其次，感兴趣的可以去以下链接看：


作者在会议上的ppt，可以去他的上下载。

Cumulus是开源的系统，链接也在作者的主页上。