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

原文: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理论上对备份的吞吐率不会造成大影响。

你可能感兴趣的:(减少在线去重造成的数据碎片)