减少在线去重造成的数据碎片

原文：Reducing Impact of Data Fragmentation Caused by In-line Deduplication。

这篇文章发表在SYSTOR’12上，主题也是数据去重的碎片问题。不知道是我的英文问题，还是他写作问题，论文读起来很不顺畅。

文章发现了一个重要的矛盾：用户喜欢恢复最近的版本，但是最近的版本碎片最严重，恢复最慢。因此使用重写+垃圾回收的方式解决这个问题。事实上这个矛盾也是我所做工作的出发点，重复了啊，伤不起！

1.CBR算法

文章的idea并不复杂，但是作者绕来绕去，弄出一大堆名词，搞得很难看懂。文章没有考虑惯用的container存储，而是假设直接按块存储。他有几个名词：

1. block context，指的是紧跟数据块后面的若干数据块，固定长度；
2. stream context，就是写入数据流的数据块的上下文，紧跟数据块后将要被写入的数据块；
3. disk context，是磁盘上数据块的上下文；
4. rewrite limit，重写数据块的上限，因为重写有开销，这个上限限制了重写数据块的数量；
5. decision block，当前需要决定是否进行重写的重复数据块；
6. rewrite utility，做决定的依据，比较decision block的stream context和disk context，等于未出现在stream context中的disk context数据块，除以disk context的大小，值越大说明碎片越严重，decision block越应该重写；
7. minimal rewrite utility，这是一个常数（=70%），当decision block的rewrite utility低于该数据，就不应该重写；
8. best-5%，到目前为止，遇到的rewrite utility最大的前5%数据块集合，大于minimal rewrite utility的decision block可能很多，超过了rewrite limit，所以应该尽量选取其中rewrite utility最大的block；
9. current utility threshold，best-5%集合中最小的rewrite utility，会不断变化，rewrite utility大于max< min rewrite utility, current utility threshold>的decision block将会被重写。

算法需要一个缓冲区来容纳stream context，写请求首先会充满缓冲区，对于每个请求都要决定它的重复状态，新数据块照常写入磁盘，对于重复数据块，将根据rewrite utility决定是否重写。当数据块被判为重复时，索引会返回其在磁盘的位置，接下来需要分析其stream context的情况，对于stream context中的每一个请求都查询索引，根据其位置判断是否处于disk context中，由于disk context是定长的，因此就可以计算出decision block的rewrite utility。如果rewrite utility大于max< min rewrite utility, current rewrite utility>，decision block将要被重写，移动到下一个重复数据块继续循环；反之，decision block和stream context中的所有重复数据块都不需要重写，因为他们的碎片情况并不严重。注意到这里的操作是不对称的。

对于旧数据块，在后台进行处理，可以放在删除等操作一起。文章并没有讨论这方面。

2.讨论

1. 本文改善近期作业的恢复性能，牺牲旧作业的视角很好；
2. 和MASCOTS’12的文章一样，没有深入研究内部碎片对性能的影响和解决方案；
3. 我认为高估了rewrite的开销，因为去重是可以流水线的，rabin分块的吞吐率是磁盘顺序写的吞吐率的2倍左右，rewrite理论上对备份的吞吐率不会造成大影响。