从嘉の小站

Embedded system, Operating system & AI. Reading, Movie & Life.

[译] [NAND Flash] 6. The Write Cliff

[译] [NAND Flash] 6. The Write Cliff

原文链接:https://flashdba.com/2014/11/24/understanding-flash-the-write-cliff/

可预测行为

系统行为的可预测性是非常重要的。如果知道一个系统任何时间的行为,我们就可以计划对应的操作。

当flash设备即将占满时,包含有用数据的page将要重定位,以进行block擦除操作。但是这里需要考虑两个问题:

  • 每个flash die 一次只能执行一个操作(有些flash是每个plane上一次只能执行一个操作),这就意味着,如果你正在擦除block A,那么对block Z的读取操作将必须 排队(queue),尽管这是die中与block A完全无关的另一个block。
  • 擦除操作实在太 了。对于MLC flash,擦除操作可能需要3 milliseconds,而读取操作只需要~50microseconds。编程操作(写入操作)耗时介于读取操作与擦除操作之间。

因此,基于上述信息,若一个用户只是简单地以可预测的速率读取数据,将可能突然发现,延迟峰值会比预期的50us高出大约60倍(如果读取操作被排到擦除操作之后的话)。

Background vs Active / Foreground Garbage Collection

现在我们考虑,当用户操作(例如,主机读/写)排在背景操作(例如,flash translation layer所做的系列工作)之后时,所带来的性能问题。我们应当使所有的背景操作在不影响用户的情况下进行。

如果垃圾收集工作以不影响用户的active I/O操作的方式进行,我们就称其为 背景垃圾收集 (background garbage collection, BGC)。BGC隐藏了擦除操作的影响,并且带来了更稳定、可预测的主机I/O时间。

反之,若某一时间段内,改变的数据量大于BGC可以维系的擦除量,那么系统可供写入的的free space将被耗尽。这种情况我们称其为 前景垃圾收集 (foreground garbage collection, or active garbage collection, AGC)。在AGC中,用户I/O操作将不可避免地排在背景操作之后,若这些I/O请求不能及时执行,将会被操作系统kill掉。 冗余机制能一定程度上缓解这一问题,但治标不治本,我们仍有可能会用完所有空余空间。

The Infamous Write Cliff

对write cliff的讨论一直很多,主要观点集中于如下几个方面:

  • 有些文章说这不再是一个问题 http://flashstorageguy.wordpress.com/2013/05/16/writecliff/
  • 有些文章说这将导致很严重的问题 http://storagegaga.com/not-all-ssds-are-the-same/
  • 也有些文章提供了避免write cliff的方法(原文提供的链接失效)

Flash设备都会提供一定的冗余来作为缓冲区,如果我们更新的数据量大于BGC算法能处理的数据量,系统就将使用缓冲区,直至达到AGC。此时,若我们继续向系统写入数据,就将发现,系统延迟急剧增加,而IOPS (Input/Output Operations Per Second)将下降。

有两种可能的场景,flash设备不会发生write cliff:

  • Flash设备(大多是SLC)处理垃圾收集的速度足够快,且拥有足够大的冗余空间;
  • Flash有写入限额,也就是说,它们将永远无法达到耗尽冗余空间的地步。”A chain is no stronger than its weakest link”。
admin

评论已关闭。