sundayhut's Blog

本文章为A New Metadata Update Method for Fast Recovery of SSD Cache的解读

1.SSD做缓存时元数据更新传统方法

在对SSD进行元数据更新操作时，最为保险的做法是“标记-写入-更新”

“标记”的作用是标记SSD正在写入的位置，标记作用是为了防止意外断电等特殊情况。比如在发生意外断电时再开机后，SSD中元数据被标记的部分就表示该部分的数据是更新操作未完成的操作。故这部分数据无效。

“写入”操作就是进行数据写入操作。

“更新”操作时写完后进行元数据的更新，比如将clean置位dirty。

“标记-写入-更新”三部曲虽然保险，即在断电时可以判断到底哪些数据时无效数据，但是其存在一个致命的缺点，那就是写操作要进行三次写SSD。影响了写的性能

2.Flashcache中元数据更新方法

在flashcache的实现中，将传统保险的“标记-写入-更新”这三步操作简化为“写入-更新”两部。省略第一步可以加快写操作。但是带来了一个很严重的问题。即意外断电时，存在部分写入的数据未更新，则有一些标记为clean的数据可能是还未来得及进行ditry置位操作。则SSD元数据记录中的为标记为clean的元数据对应的块全都不能使用。则cache中有效的块只有dirty状态的块。这就导致cache中大量数据的浪费，降低了性能。

3.论文思想

那么怎么解决这个问题呢？

本论文就提出一种基于“标记-写入-更新”的改进方法，核心思想主要是将第三部更新操作不单独进行，也就是并非写入完成后就立马更新元数据，而是在对该页的其他块做“标记”时，顺便进行整个块的更新。

3.1piggybacking ACK

我们知道SSD的写入单元是页，每页有多个元数据项，假设某页第一个元数据项对应的数据要进行写操作，那么我首先要标记该元数据，表明我准备进行写操作，那么在标记这个元数据时要写整个页，所以，我可以把内存中显示“更新”完成的元数据页同步到SSD中。那么相当于“更新”和“标记”合并在一起完成，不必进行三次写入操作。由于SSD上的元数据的“更新”操作不是及时的，故论文里把这个方法叫做Lazy-Update Following an Update-Write。

为了实现上述思想，每个元数据项有个标记为，该位表示SSD数据正在被更新。下面以一个实际操作为例，说明该流程。现要对一个page进行写操作。

step1：进行RAM和SSD上元数据置1操作，表明元数据对应数据进行写操作，即图中1,2

step2：进行SSD数据的写操作，即图中3

step3：对RAM的元数据进行及时更新，即图中4，由1置位0，表明当前是有用数据

最后图中箭头的piggybacking是指更新SSD中的元数据，即由当SSD元数据所在的page要进行别的块的step1操作时，顺带更新。

3.1总结：

思想基于“标记-写-更新”这一元数据处理的策略，将同一page不同元数据的“更新”和“标记”在写元数据页时同时完成。通过这种方式将“标记-写-更新”的三次写SSD操作下降至两次。但与此同时，有了“正在更新”的标记，使得系统意外断电后重启时，SSD中clean标记位的数据就成了可用数据，在这点上与flashcache实现相比，很大程度上提高了意外断电时缓存数据的可用率

3.2滑动窗口思想

在SSD中最后一步的“更新”操作虽然是延后的，但是由于写操作具有局部性，所以说，元数据页被写的频率是很高的，也就是说基本能及时将“更新”标记从内存中同步。但是也要考虑极端情况，该情况如下：

假设SSD中每个元数据页存放了320个元数据项，在意外断电发生时，每个元数据页中都有1个元数据项没有及时地跟内存中的元数据同步，也就是还未进行最后一步的元数据“更新”操作，那么这些元数据对应的数据就为无效数据，若缓存SSD的总容量为320G，则重新启动时SSD缓存中就有1G的内容是无效的。为了进一步减少无效数据的大小，论文提出了另一种机制：滑动窗口

这个滑动窗口里记录了整个SSD中写操作的最后一步“更新”还未来得及与内存同步的元数据项，当窗口中元数据项的个数达到了窗口大小设定的阈值时，就回进行强制写回操作。

之所以叫做滑动窗口，是因为采取了类似于TCP的滑动窗口方法，这个窗口只有当最先一个元数据被确定做完了“更新”操作后，才会滑动。另外这个窗口在每次进行SSD元数据页的更新时都会写入到SSD，滑动窗口是带有时间戳标志的。

3.2总结

滑动窗口从全局上对SSD上未做更新的元数据进行了把控，在3.1的基础上进一步增大了意外断电重启的缓存中可用数据的量。

但关于这一部分我还没有很看懂，关于为什么要滑动窗口，为什么滑动窗口还要有时间戳都没有理解。欢迎大家进行讨论

该论文网址：

http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=06665346