有前途的全新SSD数据放置方法—NVMe FDP
作者:全球开放生态系统团队(GOST)
撰稿人:Arun George
灵活数据放置(FDP)技术最近在NVMe SSD领域引起了广泛关注。 这篇博文将详细介绍NVMe FDP,并介绍其关键概念。 我们将讨论FDP如何融入NVMe生态系统,以及将FDP集成到软件栈中意味着什么。 如果您是一名工程师、架构师、经理、营销专家,或者是对最新创新感兴趣的技术爱好者,那么这篇博文可能会适合您。
1. 写入放大因子(WAF)和数据放置概述
写入放大 是SSD领域的一个著名问题。写入放大因子(WAF)表示SSD响应主机写入而执行的额外NAND介质写入操作(WAF = NAND介质总写入量/主机发出的总写入量)。 由于NAND闪存介质处理写入的方式,因此需要额外的写入操作。 NAND闪存页面一旦被编程就无法被覆盖,除非再次擦除整个闪存块(1块 = N页)。 由于擦除是一项成本高昂的操作,SSD固件通过以日志结构化的方式处理写入来避免不必要的擦除操作。 因此,每一个覆盖操作都将被重定向到新的闪存页面,并且旧页面将被标记为无效。 最终会产生许多这样的无效页面。 SSD的垃圾收集(GC)过程,通过将有效页面移动到新的闪存块来处理此类页面。 GC过程还会释放这些闪存块以供擦除,最终执行新的写入操作。 除了正在进行的主机启动的写入之外,GC还会由于有效页面的移动而引发额外的写入操作。 这个过程是导致SSD写入放大因子(WAF)问题的根本原因。 WAF问题的严重程度可能根据活动主机工作负载而有所不同。例如,顺序工作负载可能不会造成太多的WAF,因为它与SSD软件的 日志结构化写入设计相匹配, 而大量覆盖写入的随机工作负载可能会导致SSD中的WAF增加。
SSD通常使用一定级别的超配块(Overprovisioned blocks)来缓冲垃圾收集过程的影响,并减少WAF。 预留空间(OP)是一种保持额外NAND介质容量(相对于暴露给主机的SSD容量)的方法。 此外,某些主机生态系统通过采用主机级预留空间技术来扩展此设备的预留空间。 主机预留空间是通过将SSD使用率限制在低于100%的容量来实现的。 但这会导致SSD容量的低效利用。
SSD数据放置技术是通过协调主机和SSD之间的数据放置,来解决WAF问题的一种尝试。 其中像开放通道SSD和NVMe-Streams等技术在业界并未获得太大关注,而像区域命名空间(ZNS)等技术则面临挑战,因为它们要求主机修改数据模式和软件栈才能实现WAF的减少。 因此,它们都没有获得足够的关注,成为业界一直在寻找的解决方案。关于本数据放置系列上一个博客文章 是深入了解数据放置技术历史的绝佳资源。
2. FDP
NVMe灵活数据放置(FDP)规范(TP4146 )已经通过正式批准,是SSD数据放置技术领域的一种新方法。 FDP是业界迄今为止在此主题上积累经验的结果。
FDP在高效SSD数据放置方面的概念在白皮书"Introduction to Flexible Data Placement: A New Era of Optimized Data Management"中有详细阐述。为了简单起见,我们在这里只关注核心概念。 对于初学者来说,可以参考白皮书 "Getting Started with Flexible Data Placement (FDP)",其中详细介绍了主机生态系统和实用工具,帮助用户开始使用FDP驱动器。
FDP中的关键思想可以总结如下图所示。 传统的(CNS)SSD仅向主机暴露一系列逻辑块寻址(LBA),而启用数据放置的SSD则会暴露与介质拓扑相关的其他属性。 FDP SSD暴露足够的属性,使主机能够将其数据流分离,并将其数据结构与介质边界对齐。 而且它不会给主机带来额外的负担,例如介质块的垃圾收集或其他介质管理负担。


2.1 介质拓扑的简化视图
灵活数据放置(FDP)允许主机对介质拓扑有简化的视图和适度的了解。 FDP SSD与其他传统驱动器一样,保持了对逻辑到物理映射、垃圾收集和NAND介质坏块管理的控制。 如果我们将这一点与其他技术进行比较,ZNS驱动器要求主机控制逻辑到物理映射和垃圾收集过程。 主机使用与传统驱动器相同的逻辑块寻址(LBA)对FDP驱动器进行寻址,但有关放置的可选数据提示除外。 FDP驱动器向主机暴露一些关键方面,以便主机能够利用它们进行数据放置。
- 回收单元(RU): RU是一组NAND块,主机写入的数据将被编程到这些块中。 根据设备固件的设计,RU可能等于超级块或子超级块(超级块是指跨所有通道、储库、晶粒和平面的NAND擦除块的集合)。 RU是主机能够跟踪写入和GC事件的粒度。 目前RU的大小通常为 ~GB。
- 回收组(RG): RG是RU的集合。 RG概念允许主机在晶粒(Die)级别执行数据隔离。 一个典型的RG由一个或多个晶粒(Die)组成。
2.2 主机隔离数据流的能力
FDP提供了名为回收单元句柄(RUH)的概念,允许主机同时写入多个RU。 这与以前的NVMe streams类似。 请注意,传统的SSD始终只会写入一个头块(或超级块)。 此外,只有当当前头块完全编程时,才会选择下一个块。 FDP通过为传入的主机数据提供多个头块,来提供多个附加点。 主机可以通过指定对数据进行编程的RUH来选择附加点。 RUH的数量取决于设备配置,并且根据产品要求通常范围在1到128之间。
2.3 来自设备的反馈
FDP与NVMe-Streams等类似技术的主要差异点之一是,设备在提供的放置语义的有效性方面,主动向主机提供反馈。 典型的反馈可能与产生的垃圾收集(GC)事件有关。 这些反馈可以定期从FDP日志寄存器中收集,并可用于微调放置语义。 请记住,反馈机制可能不在SSD的性能路径中,因此可能不会在主机软件中的关键IO路径中使用。
3. FDP对于SSD来说意味着什么?
探讨在SSD设备启用FDP意味着什么将会很有趣。 第一张图表解释了传统驱动器的架构,其中 A)显示了驱动器的简化高级介质布局。 它显示了用于主机写入的单个头块。 图表中的 B)进一步详细说明了通道,而晶粒(Dies)显示了如何跨通道管理写入附加点。 关键点在于,每个<通道、晶粒、平面>组合中的块在NAND页面上有一个写入位置,这个位置对应于头超级块的附加点。 请注意,这是一个简化的视图,具体实现可能有所不同。


下面的FDP驱动器架构图提供了略有不同的视角,而其实现方式与传统驱动器几乎相似。 FDP驱动器在回收单元句柄方面暴露多个附加点,而传统驱动器只有一个用于主机写入的附加点。 下图解释了回收单元(Reclaim Unit)的大小和组成等于超级块 (Superblock)相同的情况。 然而,这并非所有体现情况中的通用情况,并且可能根据产品需求有所不同。 在一些体现场景下可能会选择子超级块的回收单元大小,其可能仅应用于<通道、晶粒、平面>组合的一部分。


3.1 多个附加点(RUH)
由于FDP SSD提供多个附加点作为回收单元句柄,因此它可能必须保持额外的资源(例如写入缓冲区条带)来支持它。 这些开销和特定的部署需求会影响某个SSD能够支持的RUH数量。 支持许多RUH的一种方法是,将回收单元大小配置为子超级块的大小,这允许在同一个超级块中包含多个主机附加点。 然而,这可能会对SSD的性能产生影响,因为超级块大小的配置是为了在<通道、晶粒、平面>组合中同时编程时实现最大吞吐量而设计的。 因此,选择附加点(RUH)的数量是一个需要明智的决定,应该在 SSD设计时考虑性能需求和所需的灵活性。
可以总结如下:
- 较少的附加点 - 性能保证更好,但主机灵活性较低
- 较多的附加点 - 性能保证较低,但主机灵活性更高
3.2 什么是最佳的RU和RG配置?
由于子超级块RU大小允许更多RUH,因此许多基于FDP的SSD都考虑使用这种配置。 尽管拥有尽可能多的RUH和RG以便主机高效控制数据放置似乎更好,但它可能会对性能产生影响。 因此,SSD架构师需要在以下两种配置之间进行选择, 1. <small RU, many RUH>:支持更精细的数据放置控制,但性能降低;2. <big RU, few RUH>:支持较少的放置控制,但性能最大化。 同样的论点也适用于RG配置,因为拥有更多的RG可能有助于更精细的放置控制,但实现最大吞吐量的责任将由主机承担。 请注意,支持FDP的SSD可能只支持少数(可能只有一个)<RG、RUH>配置可供选择。
总结如下:
- <small RU、many RUH>或者 <many RGs>:主机控制能力更强,但SSD性能保证较低。
- <big RU、few RUH>或者<few RGs>:主机控制能力较弱,但SSD性能保证更高。
3.3 最初隔离RUH与持续隔离RUH
FDP允许SSD定义最初隔离(Initially Isolated)和持续隔离(Persistently Isolated)的RUH。 最初隔离的RUH配置意味着在主机写入时保证数据隔离,但这种隔离不会持续整个数据的生命周期。 最终的GC过程可以将这些数据与其他RUH的数据混合在一起。 持续隔离RUH意味着,数据与其他RUH的数据在数据的整个生命周期内的隔离得到了保证。 持续隔离的RUH在理论上看起来不错,但SSD可能需要更多的资源来实现它。 因此,预计最初FDP设备将与最初隔离RUH一起推出,因为它们有助于以较低的成本实现基本隔离。 Meta公司的CacheLib对FDP的测试结果表明,最初隔离的RUH已经足以实现接近1的WAF
4. FDP对主机意味着什么?
FDP的一个关键特点是它向下兼容,并且是一项可选功能。 支持FDP的SSD可以像以前一样与不支持FDP的软件栈协同运行,而无需任何开销。 同样,支持FDP的软件栈可以与非FDP SSD无缝协作,不会出现任何问题。 唯一的缺点是,此时无法享受到FDP的额外WAF优势。 由于FDP是一项可选功能,因此只有在IO命令中启用FDP(使用DTYPE和DSPEC字段)时,才会处理主机提供的提示。
4.1 何时选择FDP?
如果主机希望在尽量减少工程工作量的情况下获得大部分的数据放置优势,FDP是一项理想的技术。 这里说的“大部分”是指在“大部分”场景下,实现接近“理想值1"的SSD写入放大因子(WAF)。 使用FDP实现理想的WAF值1是完全可能的,并且这取决于工作负载。
如果主机希望在所有场景中实现SSD WAF为1,那么像分区命名空间(ZNS)这样的机制可能更适合,因为它们具有严格的顺序写入接口。 然而,如果软件栈不是这样设计的,则必须重新设计主机软件栈以形成适合这些接口的顺序I/O模式。 这会导致增加应用程序级WAF,从而抵消设备级WAF的任何改进,并且端到端WAF将保持不变。 因此,这些严格的写入接口只有在主机软件从一开始就按照“WAF = 1”的目标设计时才正常运行。 如果主机希望在不付出太多工程努力的情况下,享受大部分WAF优势,并且不对应用程序级WAF造成任何影响,那么FDP是理想的选择。
4.2 FDP的设计考虑因素
4.2.1 哪些工作负载可以从RUH隔离中受益?
有人应该分析工作量并弄清楚是否可以从RUH隔离中受益。 具有多个不同IO模式且包含热数据温度(多次覆盖)的工作负载往往会导致较高的WAF,这类工作负载肯定能从基于FDP RUH的隔离中获益。
例如,以下工作负载可以轻松从FDP中受益。
- 具有固有热/冷数据分离的工作负载,如SSD缓存
- 需要基于租户隔离的工作负载
- 具有大量元数据开销的工作负载(可以将元数据和数据分离以改善WAF和尾延迟)
- 能够识别出具有独立写入线程的工作负载
4.2.2 主机何时使用RG隔离?
FDP的回收组概念为主机提供了有趣的放置控制功能。 如果FDP SSD为每个晶粒(Die)提供一个RG或多个晶粒,则主机能够将需要隔离的数据放置在这些RG中,并利用它。 这种隔离可能有用的一个场景是多租户使用案例中的不同租户。 这使得一个租户可以免受其他租户在GC事件等方面的性能影响。 但这可能会付出性能降低的代价,因为RG越小SSD内部写操作中的并行性使用越少,带宽也会相应下降。 在许多场景中,每个设备只有1个RG,并让SSD利用并行性获得最佳性能的简单方案就足够了。
4.2.3 主机应该跟踪RU中的写入?
FDP允许主机跟踪RU中的写入。 使用FDP规范,主机可以了解RU中的剩余字节,甚至可以在需要时指示SSD为某个RUH选择新的RU。 虽然主机构架师可能会对这样的功能感到欣喜,但这需要谨慎处理。 这些用于RU跟踪的命令可能被实现为管理命令,并且可能比IO命令慢得多。 因此,最好将控制路径中的RU写入跟踪设计为离线验证机制,而不是在线IO跟踪方法。 此外,当多个线程同时写入同一个RUH时,RU写入跟踪会变得困难。 另一个需要考虑的因素是,当使用“IO队列深度 > 1”时,SSD控制器可能会发生命令重排。
因此,建议主机仅在以下情况下进行RU写入跟踪:
- 只有单个线程写入给定的RUH
- 使用NVMe IO队列深度 = 1
简而言之,当主机具有一致的RU大小(或类似大小)数据移动时,使用RU级别跟踪进行优化是有意义的。 否则,跟踪开销可能会超过其带来的收益。 而且需要检查此RU跟踪在现有应用程序中实现是否复杂,因为它涉及修改IO路径的行为。 此外,由于延迟增加,在“QD = 1”情况下成本可能较高。
5. 灵活数据放置(FDP)实际上如何运行?
了解FDP如何帮助实现低写入放大因素(WAF)的方式是很有趣的。 让我们以使用3个不同应用程序的、基于RUH的隔离为例,分析SSD GC行为。


从这个例子中可以清楚地看到,基于FDP的隔离有助于减轻SSD的GC过程的负载,并通过工作负载的内在无效化来释放块。 FDP确保这种释放不受具有不同生命周期的不同流/应用程序数据的影响。 因此,在上述情况下,FDP可帮助SSD维持 ~1的WAF。
6. 令人兴奋的早期结果
在三星,我们使用三星PM9D3 SSD在Meta公司(Facebook)的CacheLib部署上启用了FDP。 这项工作 已经与主流CacheLib代码合并。 整合结果非常有趣。 最初,CacheLib部署在SSD满负载使用时,面临高达~3.5的WAF。 因此,部署不得不将SSD利用率降低到50%,并使用50%的主机预留空间(OP),以将SSD WAF保持在1.3以下。 使用FDP Cachelib,KV Cache工作负载即使在SSD满负载使用的情况下,也能够将WAF维持在~1。 这不仅实现高效的容量利用、还带来更低的延迟(由于GC减少)以及更低的SSD功耗(同样由于GC减少)。 请关注本系列的下一篇博文,将详细介绍CacheLib生态系统中的FDP集成及其可持续性优势。


7. 接下来是什么?
NVMe FDP是一项令人兴奋的新型SSD数据放置技术。 这是业界多年来尝试解决SSD写入放大因子(WAF)问题的不同方法后得出的成果。 在为主机提供适度数据放置控制的同时,它确保数据放置目标得以实现,而不会给主机软件栈带来额外的负担。 FDP的好处体现在更好的SSD写入放大、更低的尾延迟和更低的SSD功耗。
FDP的主机生态系统已经准备就绪,Linux内核支持可通过 IOUring_Passthru 机制提供。目前,常规Linux块设备层路径中的FDP支持正处于开发的最后阶段。 请参阅 whitepaper了解有关FDP生态系统支持的更多详细信息。
随着越来越多的业界和学术界人士对这项新技术产生兴趣,预计不久将会出现更多有趣的使用场景。 目前看来,FDP的未来的确一片光明。
8. 参考文献:
1. "Introduction to Flexible Data Placement: A New Era of Optimized Data Management"
https://download.semiconductor.samsung.com/resources/white-paper/FDP_Whitepaper_102423_Final.pdf
2. "Getting Started with Flexible Data Placement"
https://download.semiconductor.samsung.com/resources/white-paper/getting-started-with-fdp-v4.pdf
3. "Nuances in FDP Implementation"
https://www.sniadeveloper.org/events/agenda/session/697
4. "A Brief History of Data Placement Technologies"
https://semiconductor.samsung.cn/news-events/tech-blog/a-brief-history-of-data-placement-technologies/