SMR磁盘学习6---SMR之Shingled magnetic recording Area Density Increase Requires New Data Management

SMR之Shingled magnetic recording Area Density Increase Requires New Data Management

1 总述

全文主要介绍了在SMR磁盘上相对于传统磁盘的数据新的组织方式。主要内容包括SMR磁盘的瓦结构特点;在host-managed SMR磁盘上和drive-managed SMR 磁盘上数据管理的挑战;在磁盘上物理块分布的模式:track瓦片形式分布,多个track组成band,存在gap track分隔band;逻辑块和物理快的映射方式,映射方式主要包括动态映射和静态映射分别不同条件下的使用特点;然后分别介绍了SMR磁盘对应host,drive,cooperatively managed下的数据管理方式;比较说明了drive-managed和host,cooperatively 对应不同的应用下的表现,工作负载,文件系统需求等;最后详细介绍了两种SMR proposal,caveat scriptor方法,对应于exposed SMR以及coop方法,对应于cooperatively managed SMR。最后简要的说明了一下未来的工作。

全文的重难点在于SMR磁盘上的数据组织形式对比分析;对齐的drive-managed SMR ,host and cooperatively managed SMR磁盘的应用分析;以及两种SMR接口的提案:caveat scriptor和coop。下面将在第二部分重点分析。

全文的组织架构如图一所示:

2 重难点分析

2.1 SMR磁盘上的数据管理

SMR磁盘上主要依据在数据保留,数据读取的限制,物理区域的分布以及逻辑块到物理快的映射方式这四个方面具体的选择不同而表现出不同的数据管理方式。

具体的区别体现在不同类型的SMR磁盘上。

2.1.1 drive-managed SMR

在drive-managed SMR磁盘中,独立的采用传统的数据保留模式来保留每个LBA的数据,而没有没和主机读取模式的任何限制。

Drive-managed SMR 允许SMR磁盘使用在任何已知的存储栈。传统磁盘的数据形式也适用于drive-managed SMR,但是会在性能表现和能量消耗上相对于传统磁盘表现有所不同。

2.1.2host-managed SMR

strictly Append 是一种host-managed SMR 上的严格限制主机写只能发生在band的末尾的已知数据组织形式。

Exposed SMR 是一种不同的host-managed SMR上的数据组织形式,在这种方式里,主机意识到了数据的分布和映射方式。Exposed SMR不限制主机的存取,但是相对于数据保留模式的管理权限给主机,它采取了另外的约束。将在后文的caveat scriptor 部分阐述。

2.1.3cooperatively managed SMR

这是一种结合了host-managed和drive-managed SMR的数据管理方式,拥有两者都有的特性,具体的方式coop,将在后文中阐述。

2.2 在应用方向上的drive-managed和host and cooperatively分析

2.2.1 alignment of drive-managed SMR to Applications

尽管在性能表现方面和传统的磁盘相比有差异,但是drive-managed SMR还是能够很好的满足多种应用。不仅不需要改变就能部署在主机上,而且能够满足市场的需求。

Drive-managed SMR比较适合个人的外设硬盘,备份存储以及存档应用。因为数据的入口是爆发性的而且是顺序的,这种方式适合drive-managed SMR磁盘,能够高效的进行写操作。

日志文件系统和copy-on-write 数据库机制能够高效的契合这种磁盘。同时,也适用于写数据块相对小并且存放相对集中的应用。由于数据尽量存放是顺序的,因此非常适用于读操作。

2.2.2 alignment of host and cooperatively SMR to Applications

Host and cooperatively managed SMR 适用于在band边界上顺序写的首尾部分被限制的情况下,此时对于数据的读速度可以达到与传统磁盘相媲美的程度。

相对于drive-managed SMR 上的垃圾回收方式,能够从主机的角度提供更加好的垃圾回收策略。而且相对而言,在成本花费,电量消耗和可靠性上,host and cooperatively SMR 在高性能存储上有更好的表现。

2.3 caveat scriptor : an exposed SMR proposal

caveat scriptor 的布局模式是静态的映射并且使用苛刻的磁盘参数。

A:磁盘参数

每一个LBA都有两个明显的参数:No overlap range 和isolation distance。No overlap range是连续的不重复写的LBA的最小距离;isolation distance是可能存在重叠的LBA中的最大距离:如图2所示。

            图2 :drive parameters

在给定的caveat scriptor模式中,所有的都有相同的DNOR和DID值,也就是caveat scriptor选择DNOR足够小,DID足够大以满足所有的磁盘。如图三所示。

在上图中,DNOR的大小是8,DID的大小是34.

B:host band construction

根据DNOR和DID参数,文中给出了3种具体的应用案例。

① random write band

band的大小小于DNOR能够得到一个随机的写band,因为LBA都被DID LBAs充分的隔开了,任何在随机写band上的数据不会因为其他块数据的写而对原来写入的数据产生影响。

② Sequential write band

充分的被DID隔开的band能够作为顺序写的band,在这样的band中,没有LBA 会被不同的band中的LBA重叠破坏。

③ Circular buffer band

如果足够的距离存在end和start之间,这里面的band就能组成circular buffer。最小的距离是DID,在垃圾回收的过程中,circular buffer会被用来存放回收空间中的非旧的数据。在数据处理的过程中保持空间的大小不变,为DID值。

C:value proposition

性能:快速,静态的映射可直接使用。

可预测性:满足各种操作反应需求。

通用性:circular buffers 即可用在顺序写band也可以用在随机写band上。

弹性: 主机可组成任意大小的bands

数据保留:由主机决定,满足存储堆栈的需求。

2.4   coop: A cooperatively managed SMR proposal

A:coop策略

Coop混合了一些drive-managed SMR的特性以及一些host-managed SMR的特性。Coop有drive-managed的数据保留模式以及host-managed的表现性能特点。Coop适合大块的顺序写以及小块的随机写。

Coop中存在band的生命周期,从band由空到满再到空的过程称为band的生命周期。Coop建立并且布局在相同大小的bands上的,周期的放置band边界。每一个band都有high water mark,代表最高的写地址,它的设置是为了优化写的地方。

主机策略负责垃圾的回收;硬盘策略负责读写和数据保存方式的管理。

B:value proposition

性能:快速,静态映射能够在满足写地址低于high water mark条件下的顺序写操作。

通用性:能满足普通的应用情况。

效率 :

较低的使用障碍:传统数据模式和标准命令能够直接被使用。

弹性:随机写的额外区域能够是LBA上的任意位置。

标准化:当前的标准命令能够继续被使用,额外加上一些查询的参数和high water mark值。

3 第三部分:总结

相关联的工作有

(1)文件系统

(2)应用软件

(3)磁盘上的数据管理方式

时间: 2024-10-13 11:38:36

SMR磁盘学习6---SMR之Shingled magnetic recording Area Density Increase Requires New Data Management的相关文章

SMR磁盘学习8---Novel Address Mappings for Shingled Write Disks

SMR磁盘学习8---Novel Address Mappings for Shingled Write Disks 第一部分:总述 本文通过改变mapping,减少SWD带来的写放大问题,主要对两个因素进行了深刻的讨论,即SG(Space Gain,空间增益)和WAR(Write Amplification Ratio,写放大比例),实现空间和性能的平衡,降低磁盘系统的开销. 第二部分:重难点详解 Update out-of-place 一.分析两种更新的模式 Update in-place

SMR磁盘学习2

在上一篇中我给出了整个SMR学习部分的思维导图,说的比较抽象,这一部分仍然是从整体上来学SMR部分:下面的部分都是总结的,更加精练的话,可以去看论文<叠瓦式磁记录磁盘的研究进展>,这篇论文是我们写的有关SMR磁盘的一个综述: 接下来的部分相对于论文中提到的会更加的详细,针对其中的一些部分,我会在后面更加详细的分析: 本文属于原创,转载请私信我,并指明出处! Shingled magnetic recording 研究现状调查分析 摘要 Shingled magnetic Recording作为

SMR磁盘学习5---skylight

Shingled Skylight-A Window on Shingled Disk Operation 论文报告 第一部分:总述 Skylight 是一种新奇的可用来逆推SMR磁盘特性的方法.主要包括软件和硬件两个部分.软件方法是使用软件I/O操作的延时来推测drive-managed SMR 磁盘的特性的.主要包括磁盘类型,persistent cache的结构和大小,cleaning算法的类型,块映射的类型以及bands的大小.硬件方法是使用高速的摄像头来跟踪磁头的移动轨迹来确认软件方法

SMR磁盘学习3---caveat-scriptor

Caveat-scriptor Write anywhere  shingled disks 论文报告 第一部分:总述 全文主要介绍了基于host-managed SMR操作的两种模式:Strict-Append和caveat-scriptor. Strict-Append模式将磁盘分为固定大小,并且严格限制磁盘的写操作必须在band的尾部进行顺序写.只允许per-band-truncate-empty命令恢复空间.是一种从物理上实现日志文件系统的方法.它将调度和执行cleaning算法的权限交

SMR磁盘学习4--HiSMRfs

HiSMRfs :a high performance file system for   shingled storage array 论文报告 第一部分:总述 HiSMRfs是一种运行在SMR磁盘上的文件系统,能够在没有重映射层的情况下管理SMR磁盘和支持随机写操作.为了达到比较好的性能,HiSMRfs分离了元数据和文件数据,并且分开管理它们.全文主要包括四个方面的内容,分别是SMR的简介,HiSMRfs的设计和实现,不同存储阵列下的性能表现,以及总结. 全文的重点在于HiSMRfs的设计与

Matplotlib学习---用matplotlib画面积图(area chart)

这里利用Nathan Yau所著的<鲜活的数据:数据可视化指南>一书中的数据,学习画图. 数据地址:http://book.flowingdata.com/ch05/data/us-population-by-age.xls 准备工作:先导入matplotlib和pandas,用pandas读取excel文件,然后创建一个图像和一个坐标轴 import pandas as pd from matplotlib import pyplot as plt population=pd.read_ex

NSURLSession学习笔记

NSURLSession学习笔记(一)简介 一.URL Session的基本概念 1.三种工作模式: 默认会话模式(default):工作模式类似于原来的NSURLConnection,使用的是基于磁盘缓存的持久化策略,使用用户keychain中保存的证书进行认证授权. 瞬时会话模式(ephemeral):该模式不使用磁盘保存任何数据.所有和会话相关的caches,证书,cookies等都被保存在RAM中,因此当程序使会话无效,这些缓存的数据就会被自动清空. 后台会话模式(background)

第八章 linux磁盘与文件系统管理g

(1) 磁盘分区后需要"格式化"的原因:这是因为每种操作系统所设置的文件属性.权限并不相同为了存放这些文件所需的数据,因此就需要将分区进行格式化,以成为操作系统能够利用的文件系统格式 (2)linux下的ext2文件系统在格式化的时候,把磁盘分区区分为多个块组,每个块组包括data block.inodetable.Superblock.File system Description.block bitmap.inode bitmap六个区段 在ext2文件系统下创建目录时,至少会分配

JMS学习(七)-ActiveMQ消息的持久存储方式之KahaDB存储

一,介绍 自ActiveMQ5.4以来,KahaDB成为了ActiveMQ默认的持久化存储方式.相比于原来的AMQ存储方式,官方宣称KahaDB使用了更少的文件描述符,并且提供了更快的存储恢复机制. 二,KahaDB存储配置 在 conf/activemq.xml 中配置如下: <broker brokerName="broker" ... > <persistenceAdapter> <kahaDB directory="activemq-da