Storage with SMR Disk


Skylight – A Window on Shingled Disk Operation

0x00 引言

这篇Paper是一篇了解SMR磁盘一篇很好的一篇Paper。这篇Paper主要的内容就是7个探究SMR磁盘性质的几个实验,设计到SMR的辨别,持久型Cache的类型、大小和位置等的信息,以及SMR的垃圾回收策略等。另外还有SMR的Block映射的方式,zone结果等的内容,

0x01 背景

SMR磁盘的基本架构如下图所示。基本的结构是track,这个和一般的磁盘一样,部分在SMR磁盘上面,磁道之间是有重叠的,提供了存储密度的同时也使得它直接顺序写入。为了缓解这个问题,这里引入了以Guard Regions分割的多个Band,不同Band之间的写入不会相互影响。不过这样随机写入的能力依然十分差,这里又引入了Persistent Cache来继续缓解这个问题,这个Persitent Cache相对于使用DRAM之类的易失存储介质而言。这个CMR的Persistent Cache作为容纳一些随机写操作。

skylight-smr

一般的SMR就靠文件系统只使用顺序写入来优化,Driver-Managed的在驱动层面优化了SMR,而另外的Host-Managed的则提供接口给主机来优化。在Driver-Managed的SMR中 SMR引入了类似于SSD中FTL的结构,SMR区域的Band会映射到Persistent Cache中的一个区域。开始写入的时候先写入到这个映射到区域,在写入到一定量的时候,这些数据会被移动到应该在的SMR的区域,这个操作被称之为cleaning。这个映射方法可能是一种静态的映射,也可能是使用一些FTL中使用的组相联 or 全相联的方式。Paper中使用了模拟的方式来构造一个测试环境,

skylight-conf

0x02 结构相关

这里是SMR结构特性的几个测试方法,

  • 磁盘类型和Persisten Cache类型。判断磁盘类型的方式是在开始的1GB进行随机写入,一般的CMR磁盘写入的延迟是一个比较平稳的,而SMR磁盘在过了一个写入一些数据之后,SMR会有一个突然的延迟显著增加。这个延迟的增加如下图所示,一个突然的延迟增加是一个数量级的增加。而在发生这个写入延迟的突然增加之前,这个写入的特性和一般的CMR写入特性类似,从而判断其Persistent Cache类型就是一般的CMR磁盘,

    skylight-type

  • Cache位置和布局。这里探测Cache的位置使用了一种叫做fregmented read的现象。当从一个SMR顺序读取的时候,如果Cache包含了一个block的新的版本,这样的话磁盘读取的时候磁头必须重新seek到Cache坐在的位置。

    skylight-layout

    这个算法如下,通过写入一个block,跳过一个block的方式,选择不同的offset重复以上的实验,

    Starting at a given offset, write a block and skip a block, and so on, writing 512 blocks in total.
    Starting at the same offset, read 1024 blocks; call average latency lat-offset.
    Repeat steps 1 and 2 at the offsets high, low, mid.
    if lathigh < latmid < latlow then
      There is a single disk cache at the ID. 
    else if lathigh > latmid > latlow then
      There is a single disk cache at the OD. else 
    if lathigh = latmid = latlow then
      There are multiple disk caches.
    else
      assert(lathigh = latlow and lathigh > latmid ) 
      There is a single disk cache in the middle.
    
  • Cleaning操作。SMR中Persistent Cache的操作一般分为两种策略,一种是积极的,即只要Cache中存在碎片后者不需要的数据就进行清理操作,另外一种就是lazy的,只有在确定必要的情况下才进行处理。

    1 Starting at a given offset, write a block and skip a block and so on, writing 512 blocks in total.
    2 Pause for 3–5 seconds.
    3 Starting at the same offset, read 1024 blocks.
    4 if latency is fixed then cleaning is aggressive else cleaning is lazy.
    

    在一个置顶的偏移,写入一个block,跳过一个block。这样写入512个block。在此操作之后停留3到5秒。然后在读取上次这些写入的位置,如果延迟是固定的,则表明这个cleaning策略是积极主动的否则是lazy的。

  • Persistent Cache大小。这里的基本思路就是在使得Cache为空的时候,写入数据,然后测量这个Cache能够容量多大的数据量。由于Persistent Cache这里存在Persistent Cache Map,这两个满了都会引发类似的延迟增加的效果。前者决定的Cache大小这里称之为Persistent Cache Raw Size,后者称之为Persistent Cache Size。为了区分这两种不同的cases,这里利用了不同的队列深度。

    // Test 6: Discovering Persistent Cache Raw Size
    1 Write with a small size and low queue depth until cleaning starts.
    2 Persistent cache raw size = number of writes × (minimum journal entry size + out-of-band data size).
      
    // Test 7: Discovering Persistent Cache Map Size
    1 Write with a small size and high queue depth until cleaning starts.
    2 Persistent cache map size = number of writes.
    

    另外一个大小估计的时候要考虑系统设置的阈值。系统设置Persistent Cache占用一个阈值,达到这个阈值之后开始进行cleaning操作。在测量到的Persistent Cache大小会是这个阈值,所以计算最终Cache大小的时候要考虑这个进去。

    skylight-cachesize

  • Band大小。为了策略Band的大小,这里利用了Cleaning操作。这里基本的方式如下,

    1 Select an accuracy granularity a, and a band size estimate b.
    2 Choose a linear region of size 100×b and divide it into a-sized blocks.
    3 Write 4 KiB to the beginning of every a-sized block, in random order.
    4 Force cleaning to run for a few seconds and read 4 KiB from the beginning of every a-sized block in sequential order.
    5 Consecutive reads with identical high latency identify a cleaned band.
    

    这里利用了cleaning操作以band为操作粒度,通过读取原有的数据和更新之后的数据合并,然后讲这些数据合并重新写入。

  • Block映射,这里利用了动态映射和静态映射两中不同的策略在两次重复写入下面的不同特性表现来探知的。如果是动态映射的,重复的写入会选择不同的物理位置,会导致和第一次不同的延迟特性的曲线图,而如果是静态映射的,重复的操作的特性是很类似的。

    Choose two adjacent iso-capacity bands a and b;
    set n to the number of blocks in a track.
    for i←0 to i<2 do
      for j←0 to j<n do
        Read block j of track 0 of band a 
        Read block j of track i of band b
    Overwrite the first two tracks of band b; force cleaning to run. 
    Repeat step 2.
    

0x04 评估

这里的具体信息可以参看[1].

SMaRT: An Approach to Shingled Magnetic Recording Translation

0x10 基本思路

有雨在SMR磁盘中,更新操作可能会是一个开销非常高的一个操作。SMR这里提出了很多的优化措施。SMR磁盘的异地更新策略是指,新写入的数据追加到一个新的位置,并且将原来的数据置为无效来缓解一些写入放大的问题。在这种方式中,SMR磁盘将磁盘的空间分为缓存和重组数据的区域,以及永久保存数据的区域。数据写入的时候,都会被先写入到前一个区域中,然后在合适的时候处理之后写入到后一个区域。这里涉及到逻辑block和物理block之间的映射关系,类似于SSD的FTL。另外一个就是将原有的数据都从一个zone中读出来,合并更新之后在写入原来的位置,这个称之为就地更新策略。SMaRT这里提出的策略是一种就地更新和异地更新结合的策略。

smart-arch

  • SMR磁盘的写入特点是由于磁道之间的重叠造成的,SMR通过在磁盘中间省去一些磁盘来将磁盘划为zone,而不同zone之间的写入不相互影响。这样的话这种思路也可以延伸到一个zone里面,通过在zone中预留出一些无效的磁盘来分开一个zone里面的数据,从而使得不同的部分之间的写入不相互影响。在Paper中选择留出的大小为1个磁道,这个依赖于SMR磁盘磁道的重叠程度。如果重叠地程度更加大,这个预留的空间可能需要更大一些。
  • SMaRT磁盘在开始的时候采用的是异地更新的方式,由于数据修改操作使得原有位置的磁道无效之后,SMaRT并不会马上将其释放作为可闲的磁道处理,而是将其作为一个类似SMR磁盘中的zone之间的安全间隙。这样,这个磁道前面的磁道就可直接使用就地更新的操作而不用担心数据安全性的问题。在这个安全间隙磁道后面的空间也变为空闲的时候,这部分的空间就可以作为一个整体回收。
  • 另外,SMaRT还利用数据的冷热来优化性能。对于热点的数据,SMaRT会额外分配一些安全间隙磁道来提高提就地更新的能力。但是对于冷的数据,这个就不用预留,而使用一般的异地更新的方式。

0x11 评估

这里的具体信息可以参看[2].

SMORE: A Cold Data Object Store for SMR Drives

0x20 基本思路

这Paper是利用SMR来作为一个冷对象存储的例子。对象存储最经典的一个论文之一是Facebook的Haystack的论文,基本的模型就是一个bitcask的模型。这里来看也基本上知道SMORE这里会使怎么做的了。SMORE的基本结构如下图。基本地数据写入有雨SMR磁盘的特点,这里肯定就是 log-structured式的写入。SMORE激昂数据和一些元数据都保存在SMR磁盘上,而讲索引的数据保存在Flash上面。在bitcask的模型中,索引是保存在内存中的,不过SMORE这里由于使用了多个大容量的SMR磁盘,索引可能占用的空间可能会是一个很大的值,这里讲索引保存在Flash中会是一个更加好的选择。

  • 在SMORE中,一个zone set表示一个zone的组,每一个组来自不同的SMR磁盘。这里数据写入的时候,会利用RAID 1的一些思路,将数据分为条带写入,达到更高的写入带宽。可以写入的zone set称之为open zone sets。一个这样的系统中存在一个or多个open zone sets。SMORE将写入的对象拆分为segemnts,这里的设计应该是应对大对象设计的,对于比较小的对象,一个object估计就对应到一个segment就可以了,每个sengemt写入一个open zone set。Segment又会被查分为fragments。这里fragment会被EC编码,编码之后的fragment的数据会和磁盘的数据对应。
  • 为了优化小对象写入的性能,这里SMORE还引入了一个NVRAM的buffer,一些小对象在这里聚集到更大之后在写入在最终的SMR磁盘上面。在GC方面,同样地,在SMORE中的GC的操作也是lazy的。这里GC的时候会贪心地选择垃圾数据最多的zone。这里的操作也没有什么特别的。

smore-arch

0x21 评估

这里的具体信息可以参看[3].

参考

  1. Skylight – A Window on Shingled Disk Operation, FAST ‘15.
  2. SMaRT: An Approach to Shingled Magnetic Recording Translation, FAST ‘17.
  3. SMORE: A Cold Data Object Store for SMR Drives, SDC 17.
  4. SMRDB: Key-Value Data Store for Shingled Magnetic Recording Disks, SYSTOR ‘15.
  5. ZEA, A Data Management Approach for SMR, HostStorage ‘16.