文献翻译HotR: Alleviating Read/Write Interference with Hot Read Data Replication for Flash Storage

HotR：通过热读数据复制减轻闪存的读/写干扰

该博文为非官方的个人翻译，仅供学习参考，禁止商用，如有误欢迎各位指出。
本博文如有侵权，请联系我立即删除。

摘要

  在读写请求混合的工作负载下，闪存的读写干扰问题仍是一个关键问题。为了显著提高读写干扰下的读性能，我们提出了一种闪存热数据复制方案，称为HotR。HotR利用闪存SSD的非对称读写性能的特性，并将常用的读数据外包给替代空间，比如：专用备用闪存芯片或者SSD内的预留空间。通过在备用的闪存空间上服务一些冲突的读请求，HotR可以缓解读请求和正在进行的写请求之间的争用，即使不是彻底消除。评估结果表明，HotR在系统性能和成本效益方面显著提高了最新方案。由此，闪存存储系统的尾延迟也将降低。

关键字： 闪存，读/写干扰，热读数据复制，性能评估

一、 介绍

  当前存储市场上有着不同类型的NAND闪存芯片。较早的SLC NAND 闪存芯片和MLC NAND闪存芯片已广泛商业化。最近，TLC NAND闪存芯片已经商业化，它代表3bit，将电压范围分为八个window。QLC闪存芯片由美光公司近期发布，它的每个存储单元存储4bit。单个存储单元编码的bit越多，SSD的容量将越大且不增加芯片尺寸，但是因为正确存储和读取bit的困难也增大了，这样也降低了可靠性。随着从SLC到MLC、TLC到QLC，NAND闪存芯片提供了更高密度和更低价格，但这是在以更低的性能和耐用性为代价。不对称的读写性能的特点也引发了读写干扰问题。

  图1（a）显示了不同NAND闪存的读写延迟。随着闪存芯片从SLC到QLC的演进，读和写访问的性能差距显著扩大，读写干扰问题日益严重。这种干扰是指当正在进行的写请求抢占可获得的闪存资源从而阻塞读请求时的现象，这会导致严重的读延迟。这种读写干扰会导致无法预测的性能，并在读写请求混合在一起的统一环境和企业环境中带来重大挑战。不幸的是，这样的读/写干扰问题没有得到足够的关注。一些现有的研究关注于垃圾回收（GC）引起的性能下降问题，因为闪存的GC操作相比其他存储类型更昂贵。可是，我们的评估与分析时，都写干扰也对读性能十分不利，因为写请求比GC操作更加频繁。

  另一方面，先前研究和我们的工作负载分析表明，应用程序访问是在只读或只写页执行。在这里，我们定义三种访问页类型。第一，如果对数据页的绝大多数（如90%或以上）访问是读（写）请求，则该页的特征为只读（只写）。第二，如果对数据页的访问读写交叉，则该页定义为混合页。此外，混合页仅占所有页的一小部分。基于以上观察，我们提出了一种用于闪存的热数据复制方案，称为HotR。HotR利用闪存SSD的非对称读写性能的特性，并将流行的读取数据外包给替代空间，比如：专用备用闪存芯片或者SSD内的预留空间。通过在备用闪存空间上服务一些冲突的读请求，HotR可以缓解读请求和正在进行的写请求之间的争用，即使不是彻底消除。评估结果表明，HotR在系统性能和成本效益方面显著提高了最新方案。所以，闪存存储系统的尾延迟也将降低。

二、 背景和动机

A. 读写干扰问题

  除了擦除操作，写操作是闪存性能瓶颈，不仅因为它们需要比读操作更多的时间，而且因为它们还会阻塞等待队列中的后续读操作。在读写请求混合的并发工作负载之下，正在进行的写请求抢占可获得的闪存资源从而阻塞读请求，我们将着称为读/写干扰问题。这样的读/写干扰导致不可预估的性能，并为闪存设计带来重大挑战。

  图1（b）显示了在表III中总结的四种不同的工作负载下，正在进行的写请求阻塞了多少百分比的读取请求，以及读/写干扰能如何导致系统性能下降。

  基准系统是没有优化的默认配置，而最优系统是指所有被干扰的读请求都能得到服务而不会被任何干扰的写请求阻塞的系统。平均33.0%(最大55.9%)的读请求被正在进行的写请求阻塞，导致平均42.8%的性能下降，Fin2工作负载的性能下降高达74.6%。

B. 相关工作

  针对读写干扰问题提出的解决方案分为两大类:基于I/O调度器的方案和基于冗余的方案。在基于I/O调度器的最具代表性的解决方案中,FIOS它利用SSD的读/写干扰来调度请求。Gao等人利用SSD丰富的并行性，提出了PIQ，将一批I/O请求之间的访问干扰降至最低。但是，所有这些I/O调度器只对批量的读和写请求进行分离，读/写干扰问题仍然存在于读和写请求批之间。为了避免这些缺点，Wu等人提出了一种P/E悬浮方案，一种设备级的调度器，以减少写引起的干扰。但是，频繁地挂起/恢复正在进行的P/E操作会带来系统开销并抑制写性能。此外，P/E悬浮需要硬件修改。

  作为基于调度器解决方案的替代方案，基于冗余的解决方案添加了空间冗余来分隔被干扰的读和写，以最小化干扰的影响。最近，Skourtis等人提出了Rails，它利用镜像冗余，通过物理上的读写分离，在读写混合工作负载下提供可预测的读性能。然而，由于复制冗余，Rails的空间开销相当高。相比之下，TTFlash利用SSD芯片间的奇偶冗余，通过读重构来缓解GC造成的读性能变化。TTFlash的思想可能适用于缓解由写引起的读性能下降。然而,我们的实验结果表明TTFlash是有害的，因为读重构将导致闪存芯片内的读请求数量增加，这加剧了读/写干扰问题,显示在第四部分性能评估。此外,Rails和TTFlash解决读/写干扰问题是通过添加和重组低级闪存设备资源,但是没有利用高层工作负载特征。

C. 工作负载特性和动机

  理解工作负载特性对于存储系统的设计非常重要。为此，我们根据工作负载如何访问存储在页中的数据，将闪存页分为以下三种不同类型:

1. 读密集型数据页(RI):如果对数据页的绝大多数访问(>90%)是读请求，则认为该页是读密集型;
2. 写密集型数据页(WI):如果对一个数据页的绝大多数访问(>90%)都是写请求，则该页被认为是写密集型;
3. 混合数据(MIX):如果对数据页的访问既不是RI也不是WI，即这个页面被认为是混合的。

  图1©显示了在第四节表III中列出的四种不同工作负载中，三种类型的数据页的分布。大多数读请求访问读密集型数据页，而大多数写请求访问写密集型数据页。平均只有9.6%的页面是混合数据页面。这些观察结果也与之前的研究报道的[10]，[19]一致。更重要的是，这些工作负载特征意味着热读密集型数据页不会经常被写请求更新。

  随着闪存芯片从SLC向MLC、TLC和QLC的演进，读写访问之间的性能差距大幅扩大。因此，读性能不仅会显著降低，还会因为正在进行的写请求而变得不可预测。结合对工作负载特征的了解，激发了HotR的设计，可将热读取密集型数据页主动迁移到预先保留的空间（比如临时空间，例如：专用闪存芯片或SSD内的预留空间 ）以缓解正在进行的写请求和传入的读请求之间的争用，即使不是完全消除。这有助于同时提高用户I/O性能和减少闪存存储系统的延迟。表I提供了HotR和最新方案之间的高级比较。我们提出的HotR方案是正交的，可以很容易地纳入现有的系统级I/O调度，以进一步缓解闪存SSD的读/写干扰问题。

三、 HotR

A. HotR的系统概览

  图2显示了我们在闪存SSD中提出的HotR的系统概述。在我们当前的设计中，HotR被集成到SSD的闪存转换层中。但是，HotR也可以在其他系统软件层中实现，例如闪存存储系统的I/O调度程序和RAID控制器层。

  如图2所示，HotR包含五个关键功能模块：热数据识别，按需数据迁移器，冲突检测，请求分发器和管理接口。热数据识别负责监视读取数据页的流行度，以帮助按需数据迁移器迁移流行的读数据页并管理暂存空间中重定向数据的数据布局。暂存空间可以是专用的闪存芯片，也可以是SSD内的预留空间，在本文的其余部分中，我们都将称为暂存空间，为图2中的红色部分。冲突检测负责检测由闪存芯片中被正在处理的写请求所阻塞的冲突读请求。请求分发器负责将用户I/O请求重定向到适当的位置，原始地址或暂存空间中的地址。SSD的原始地址在本文的其余部分称为闪存芯片，为图2中的蓝色部分。

B. 热数据识别和迁移

  识别热读数据页对HotR提前迁移热读数据页，以减轻读/写干扰非常重要。为了捕获用户应用程序的访问新近度和频率模式，我们设计并实现了R-LRU数据结构，这是热数据识别模块中的一个LRU样式的列表，如图3所示。R-LRU标识SSD的每个闪存芯片上的热读数据页，并存储最近读数据页的元数据信息，包括D-offset、R-offset和Count值。

• D-offset表示读取数据页在闪存芯片上的偏移量。当读数据页被标识为热读数据页并插入到R-LRU列表中时，它被初始化。

• R-offset表示读数据页在暂存空间中的偏移量。当初始化条目并将其插入R-LRU列表时，它被填充为NULL。当读数据页被请求和迁移到暂存空间时，将对其进行更新。因此，它还表示读数据页是否迁移到暂存空间。

• Count表示已访问读数据页的次数，以捕获访问频率模式。
  

  基于R-LRU，可以识别最近和频繁访问的读数据页，并主动迁移到暂存空间。此外，常用的读取数据页根据其在SSD的每个闪存芯片中的位置进行分类。如果正在进行的写请求位于相同的闪存芯片中，则很容易查询和确定是否应该在暂存空间处理冲突的读请求。由于暂存空间的容量有限，所以并不是所有常用的读数据页都要迁移。在我们当前的设计中，可以迁移的流行数据页面的百分比是通过管理接口配置的。此外，当用户应用程序请求SSD的常用读数据页时，它们会被并发地迁移到暂存空间，R-LRU会相应地更新，并由随按需数据迁移器模块填充R-offset作为读数据页在暂存空间中的偏移量。因此，在不影响闪存系统性能的情况下，减少了常用数据页的迁移开销。

C. 请求处理工作流

  图4显示了读写请求的处理工作流。在HotR中，所有的写请求都由闪存芯片处理。为了确保数据一致性，还会检查和查询R-LRU列表。如果写请求命中R-LRU列表中的一个条目，且R -LRU不为空，则从R-LRU列表中删除该条目，以确保后续的读请求获取最新的数据页。暂存空间中相应的读数据页同时被标记为无效。如果R-offset为NULL，则表示读取的数据页没有迁移到暂存空间。无论写入请求是否命中R-LRU，后续读请求的数据一致性都不会受到影响，因为暂存空间中迁移的读数据页始终是最新的，并且与存储在闪存芯片上的数据页相同。

  由于缓冲区和I/O调度器优化，到达设备级别的写请求通常是突发的。大量的写请求和较长的程序延迟使大多数闪存芯片繁忙，并阻塞传入的读请求。冲突检测模块监视闪存芯片的程序状态，并返回结果，该结果表示传入的读请求是否被阻塞。如果读请求被阻塞，请求分发模块将查询R-LRU列表，以检查读请求是否在R-LRU列表中出现。如果它命中并且相应的R-offset不为空，则读请求由暂存空间提供服务，并且相应的Count值增加1。如果它命中并且相应的R-offset为NULL，则读请求由闪存芯片处理。读数据页从闪存芯片获取并返回到上层之后，HotR同时将它们写入暂存空间，并更新R-LRU列表中条目的R-offset和Count值。对于未命中的读请求，将初始化条目并将其插入R-LRU列表，以便识别热读数据页。

四、 性能评估

A. 评估设定和方法

  为了评估我们提出的HotR方案的有效性，我们实现了一个HotR方案的原型，将其集成到微软研究院(MSR)[1]开发的开源SSD模拟器中。表II和图1(a)分别总结了仿真器中使用的SSD具体参数值和不同NAND flash类型的性能特征。实验评估默认使用基于TLC的NAND flash芯片。我们既使用实际的企业级工作负载，也使用类似于HPC的合成工作负载。financial 2工作负载收集自在大型金融机构[15]上运行的OLTP应用程序，其他企业级工作负载收集自Microsoft Cambridge Research[4]。表三总结了这些工作负载的主要特点。类似于HPC的合成工作负载允许我们灵活地改变参数，比如读/写比率、请求的到达时间、读访问概率和顺序性。我们将HotR方案与没有任何优化(基线)的原始系统、Rails[14]和TTFlash[20]方案在平均响应时间和成本-延迟产品方面进行比较，以提供成本效益的度量。

B. 性能结果和分析

  图5显示了由4个工作负载驱动的平均响应时间，它被归一化为基准系统的平均响应时间，没有进行任何优化。默认情况下，Rails使用4+4 RAID1配置，TTFlash使用4+1 RAID5配置。10%的热读数据页在HotR中迁移。首先，HotR将基准方案的平均响应时间提高了54.0%，平均为21.8%。显著提升的性能源自于平均17.8%的用户读请求被重定向到暂存空间，如图6所示。大多数迁移后的用户读请求，（这些请求没有迁移，将被正在进行的写请求阻塞），导致读请求和写请求之间的争用得到显著缓解。从读请求的角度来看，由于避免了编程操作(写操作)造成的长时间延迟，平均响应时间显著降低。
  其次，HotR的性能比TTFlash好得多，但比Rails差。这是因为，TTFlash通过基于奇偶校验冗余利用读重构，在避免用户读请求和写请求之间的干扰的同时，会产生大量的内部读请求，使得读/写干扰问题更加严重。因此，TTFlash不能扩展到也不适合解决闪存的读写干扰问题。相比之下，Rails不仅可以消除读/写干扰问题，还可以利用复制冗余提供的读平衡。图6所示的Rails和HotR方案重定向读请求的百分比表明，不仅所有被干扰的读请求，而且一些其他的读请求也被Rails重定向。然而，Rails通过利用复制冗余实现的显著性能改进带来了很高的空间开销。之前的研究[2]已经表明，复制对于闪存存储是不经济的，这与我们的成本效益结果是一致的。

  为了研究在不同工作负载下HotR方案对尾延迟的影响，我们在图8中绘制了第95、97、98、99和99.5个百分点处的I/O延迟。我们可以看到，HotR在尾延迟性能方面始终显著优于基准系统。虽然尾延迟主要是由flash芯片的编程操作引起的，但是HotR方案中的读请求重定向可以缓解由写引起的读性能下降。因此，具有长延迟的请求的百分比相应地降低了。图8还显示，在所有方案中，Rails的尾延迟最好，TTFlash的尾延迟最差。原因是Rails可以通过数据复制消除几乎所有的读/写干扰。然而，TTFlash的读重构产生了大量的内部读请求，从而加剧了读写干扰问题。例如，TTFlash的响应时间超过500ms，在Fin2和HPC 46工作负载下，这个响应时间太大，无法在图8中显示。

  为了有意义地估计和量化HotR的成本效益与最新的冗余方案进行比较，我们使用成本-延迟产品作为衡量成本的方法，并从计算机体系结构文献中常用的能源延迟产品中汲取了灵感，量化能效。成本主要取决于每种方案消耗的额外存储空间，并根据基准系统进行了归一化，而没有任何额外的空间开销。方案的成本-延迟产品的值越低，该方案的成本效益就越高。图7就成本-延迟产品而言，根据延迟和本节前面部分介绍的跟踪驱动实验获得的成本结果，显示了不同方案的成本效益。

  HotR显然是最具成本效益的，其性能比Rails和TTFlash分别高出31.6%和65.7%，其成本效益甚至比基准系统高出13.9%。HotR在成本效益衡量方面的优势有两方面的原因。首先，通过利用工作负载特性，只有热读数据页被迁移到暂存空间，这比Rails和TTFlash方案消耗的空间开销要小得多。虽然并不是所有冲突读请求都被迁移，但是HotR平均避免了63.0%的冲突读请求。其次，通过在暂存空间中放置热读数据页，可以显著降低冲突读请求的访问延迟。这些冲突的读请求不会受到写请求的进一步干扰，从而减少了它们的访问延迟并提高了系统性能。TTFlash通过产生大量内部读请求的读重构，避免了用户读请求和用户写请求之间的干扰。这些增加的内部读请求可能与用户的写请求发生冲突，从而抵消了读重构的优点，并加剧了读/写干扰问题。虽然TTFlash的空间开销比Rails小，但是它的性能却比Rails差。因此，Rails和TTFlash都不是经济有效的，它们甚至比没有任何优化的基准系统更差。相比之下，HotR利用工作负载特性在系统性能和空间开销之间取得了更好的平衡，从而在所有方案中实现了最佳的成本效益。

  HotR方案的性能可能会受到NAND闪存芯片类型的影响。 图9显示了基准系统上HotR方案的性能加速结果，其中有10％的读取数据页被热迁移，这是由四个工作负载驱动的从SLC到MLC，TLC和QLC的不同闪存芯片的函数。 随着从SLC到QLC的每单元比特密度的增加，HotR实现的性能加速也相应提高。 原因是基于TLC和QLC的闪存芯片具有更长的程序延迟，如图1（a）所示，延长了冲突读取请求的延迟。 此外，较长的程序延迟也会导致较大百分比的读取请求被正在进行的写请求阻止。 另一方面，我们也看到HotR改善了基于SLC和MLC的闪存存储的系统性能，尽管该性能不如基于TLC和QLC的闪存存储显著。

五、 结论

  本文提出了HotR，通过兼顾工作负载特征和设备特征来解决闪存存储的读写干扰问题。 通过主动将频繁读取的数据页复制到暂存空间中，HotR方案从闪存芯片的原始地址中删除了一些冲突的读取请求。 大量跟踪驱动的实验结果表明，HotR显着提高了最新方法的系统性能和成本效益。 因此，基于闪存的存储系统的尾部等待时间也减少了。

致谢

略

参考文献

[1] N. Agrawal, V. Prabhakaran, T. Wobber, J. Davis, M. Manasse, and R. Panigrahy. Design Tradeoffs for SSD Performance. In USENIX ATC’08, Jun. 2008.
[2] M. Balakrishnan, A. Kadav, V. Prabhakaran, and Dahlia Malkhi. Differential RAID: Rethinking RAID for SSD Reliability. In EuroSys’10, Apr. 2010.
[3] G. Belelloch, J. Fineman, P. Gibbons, Y. Gu, and J. Shun. Sorting with Asymmetric Read and Write Costs. In SPAA’15, Jun. 2015.
[4] Block I/O Traces in SNIA. http://iotta.snia.org/tracetypes/3.
[5] Y. Cai, S. Ghose, E. Haratsch, Y. Luo, and O. Mutlu. Error Characterization, Mitigation, and Recovery in Flash-Memory-Based Solid-State Drives. Proceedings of the IEEE, 105(9):1666–1704, 2017.
[6] W. Choi, M. Jung, and M. Kandemir. Parallelizing Garbage Collection with I/O to Improve Flash Resource Utilization. In HPDC’18, Jun. 2018.
[7] J. Cui, Y. Zhang, J. Huang, W. Wu, and J. Yang. ShadowGC: Cooperative Garbage Collection with Multi-level Buffer for Performance Improvement in NAND Flash-based SSDs. In DATE’18, Mar. 2018.
[8] C. Gao, L. Shi, M. Zhao, C. Xue, K. Wu, and E. Sha. Exploiting parallelism in I/O scheduling for access conflict minimization in flashbased solid state drives. In MSST’14, May 2014.
[9] S. Koh, C. Lee, M. Kwon, and M. Jung. Exploring System Challenges of Ultra-Low Latency Solid State Drives. In HotStorage’18, Jun. 2018.
[10] Q. Li, L. Shi, C. Xue, K. Wu, C. Ji, Q. Zhuge, and E. Sha. Access Characteristic Guided Read and Write Cost Regulation for Performance Improvement on Flash Memory. In FAST’16, Feb. 2016. [11] B. Mao and S. Wu. Exploiting Request Characteristics and Internal Parallelism to Improve SSD Performance. In ICCD’15, Oct. 2015.
[12] S. Park and K. Shen. FIOS: A Fair, Efficient Flash I/O Scheduler. In FAST’12, Feb. 2012. [13] QLC. https://www.micron.com/products/advanced-solutions/qlc-nand.
[14] D. Skourtis, D. Achlioptas, N. Watkins, C. Maltzahn, and S. Brandt. Flash on Rails: Consistent Flash Performance through Redundancy. In USENIX’14, Aug. 2014.
[15] UMass Trace Repository. http://traces.cs.umass.edu/index.php/.
[16] H.Wang,J.Zhang,S.Shridhar,G.Park,M.Jung,andN.Kim. DUANG: Fast and Lightweight Page Migration in Asymmetric Memory Systems. In HPCA’16, Mar. 2016. [17] G. Wu and B. He. Reducing SSD Read Latency via NAND Flash Program and Erase Suspension. In FAST’12, Feb. 2012.
[18] S. Wu, Y. Lin, B. Mao, and H. Jiang. GCaR: Garbage Collection aware Cache Management with Improved Performance for Flash-based SSDs. In ICS’16, Jun. 2016. [19] S. Wu, W. Zhu, G. Liu, H. Jiang, and B. Mao. GC-aware Request Steering with Improved Performance and Reliability for SSD-based RAIDs. In IPDPS’18, May 2018.
[20] S. Yan, H. Li, M. Hao, H. Tong, S. Sundararaman, A. Chien, and H. Gunawi. Tiny-Tail Flash: Near-Perfect Elimination of Garbage Collection Tail Latencies in NAND SSDs. In FAST’17, Feb. 2017.