1、从ZNS说起

Zone Namespace（ZNS）在2020年开始广泛讨论，2021年在NVMe协议组织基本定稿发布。ZNS对于存储系统或者云系统，在系统侧可控制IO在SSD内的具体写入位置，通过系统侧的主动垃圾回收（Garbage Collection，简称GC），将SSD内的GC削减到0。一方面，可以减少系统和SSD两层GC带来的写放大和读写冲突，延长盘片使用寿命，也保证系统带宽和QoS。另一方面，由于SSD内基本不需要GC，可以减少SSD内的冗余空间（Over-Provisioning，简称OP），使OP基本减到零，对于SSD内部管理表项也带来简化，从而削减企业级SSD的DRAM。

对于系统应用来说，一边能保性能，一边能降成本增寿命，这么两全其美的好处，立即得到了Flash Memory Summit（FMS）、Open Compute Project（OCP）等组织和技术社区热议。但是，技术上只谈好处，不谈开销是不合理的。笔者认为，ZNS主要的开销是在系统侧“做得太多”。

ZNS要求单个Zone之内的LBA地址，必须是严格顺序追加写的，与SSD写Flash的方式相对应。系统应用的管理粒度需要与Zone大小对齐，按Zone粒度进行写入和回收。这样，使得系统对SSD的操作方式，与SSD操作NAND的方式相符，SSD将Zone粒度映射到NAND的Block粒度，即可达成零GC的操作。

那么问题来了，严格顺序追加写对系统应用带来的约束太大。如果按ZNS定义的传统写方式，系统对单个Zone操作的Queue Depth只能是1，即对一个Zone只能做串行写，这对系统处理的约束很大。后来ZNS增加Append方式和ZRWA方式作为补充，改善了对追加写的约束，系统用起来还是会有些别扭。此外，对于SSD写异常，由于是严格顺序追加，系统也需要与SSD同步出错Zone的写位置，Zone能否继续追加等信息，才能进行后续的策略处理。

SSD要获得零GC收益，必须将Zone粒度和NAND的Block粒度对齐。NAND厂家基于工艺和成本考虑，不同厂家、不同代次的NAND Flash，Block大小均不相同。随着NAND厂家工艺叠层的增加，NAND Block大小持续增大，目前Block大小已基本超过100MB。这已经比系统应用一般的文件或者块管理粒度要大得多。如果系统应用只通过Zone跟单Block对齐，要跑满SSD性能，系统应用还需知道Zone和NAND通道、Die的物理拓扑关系，才能用满NAND并发。如果系统应用希望单Zone能跑满SSD性能，SSD实现需要将多个通道/Die的Block绑定成一个Zone，这样单Zone容量都到达GB级别了。此外，SSD盘内的静态Wear Leveling、NAND Data Retention/Disturb等场景，都需要通知系统进行搬移。

对消费级的单盘系统（如手机、笔记本电脑等），本身存储性能和QoS要求不高，在系统应用算力有剩余情况下，这些约束都可以接受。譬如苹果手机通过类ZNS方式获得了令人惊讶的用户体验。但对于企业级或者云场景的多盘存储系统，情况会更为复杂。存储系统需要考虑多供应、坏盘替换、利旧等场景，很难保证一个存储池内都是同NAND厂家同代次的SSD。这样系统侧就会面对多种Zone粒度的管理，对存储系统进行多备份、EC条带选择、垃圾回收等方面设计考虑，都会变得更为困难。

2、由多流演进而来

2021年，Google带着Flexible Data Placement（FDP）的概念和自研的Smart FTL应用进行宣讲，并联合Meta在2022年逐步把FDP推入到NVMe标准协议。近期，FDP议题在OCP进行了多次演进和讨论，逐步得到业界的重视。同样是为了追求削减SSD GC，降低写放大为目标。FDP和ZNS走的倒是不同的路线。

ZNS沿着Open Channel的路线演进，Open Channel方式本身是把NAND Flash操作向系统应用呈现，通过系统直接控制NAND Flash操作来极大化利用NAND。这样的问题是，系统应用需要知道SSD上的NAND具体操作方式和物理拓扑，NAND代次演进和厂家差异，系统应用也需要进行适配。ZNS是在这基础上进行一层抽象，抽象成Zone粒度和追加写方式，把NAND Flash具体操作和粒度进行了一层屏蔽。

Multi-Stream多流则是在标准命令接口上，添加数据的冷热度标识，由SSD对数据进行分类存放和GC，来减少SSD的写放大，这对系统就容易适配多了。SSD在支持多流情况下，也是需要做GC的，这样只能一定程度的削减OP，譬如从3DWPD盘改为1DWPD盘就能符合系统应用；另外，系统应用层面的GC和SSD层面GC冲突，会带来QoS不利影响。后来IO Determinism主要在于通过NVM Set对SSD空间进行划分和性能隔离，通过Deterministic Window (DTWIN)和Non-Deterministic Window (NDWIN)的机制交互，让系统应用知道SSD的NVM Set的QoS状态，系统按一定规则可以得到确定性时延。与Open Channel路线相比，多流路线更看重系统和SSD盘片的解耦，以及系统应用的向下兼容。由此也更容易获得系统应用的支持和落地。FDP就是在此路线上做进一步精细化演进。

3、FDP是什么

从FDP的操作模型来看，FDP是在IO写命令上，使用Directive Specific (DSPEC)字段（也是stream标识字段），来标识Reclaim Group和Placement Handle。Placement Handle在SSD内映射到Reclaim Unit Handle。这协议一下子就整了很多名词，实际上，FDP在SSD内就是围绕Reclaim Group和Reclaim Unit进行操作。

SSD可以将并发NAND拓扑划分为多个Reclaim Group，做成Reclaim Group间性能隔离。将SSD内的NAND物理block（或者Super block），划为Reclaim Unit。那么，Reclaim Unit Handle指向不同的Reclaim Unit，可以理解成写入不同的NAND物理block的写指针。从系统应用看来，就是在标准IO写时，通过DSPEC标识，指定写入到特定性能隔离区域Reclaim Group里面，放置到按类别（不同业务类型或者冷热度）区分的Reclaim Unit（即NAND block）。

与ZNS不同，FDP的写方式并没有与Reclaim Unit对齐，而且FDP是允许SSD盘内GC的。这样，SSD盘片在NAND异常处理的主动权就大得多。FPD定义Reclaim Unit Open时间，超过时间会造成Reclaim Unit切换。而且，SSD盘内由于异常处理等原因造成的Reclaim Unit切换都要事件上报。这样看，FPD就是要求更严格的多流或者IOD模式。

但是，FDP通过一些机制，避免与系统应用GC冲突，尽量减少SSD盘内GC。FDP定义Estimated Reclaim Unit Time Limit (ERUTL)，用于表示Reclaim Unit写入后到被SSD盘内主动回收的时间。在未到时间前，系统应用主动回收，就不会触发SSD盘内GC。事实上，对系统应用中的热数据或者前台写入数据，在一定时间内系统应用进行整理回收。而系统中的冷数据，系统应用不会搬移，SSD内部会根据NAND特性主动进行GC和Wear Leveling。对于SSD应用能力较强的系统，可以通过感知Reclaim Unit粒度，根据Reclaim Unit制定系统GC策略，从而获得更好的效果。FDP通过与系统间的模糊策略交互，使SSD盘只有弱GC，减少写放大，降低SSD盘的OP。同时也减少系统和SSD两层GC冲突，保障系统侧的时延和QoS。

OCP的会议观点中认为，FDP具有比较好的向后兼容能力：1）FDP可以在标准设备中激活；2）应用在不理解FDP的情况下也可获得收益；3）理解FDP的应用可以获得更多收益。不修改应用情况下，将不同应用或者不同Namespace分配到不同Reclaim Unit Handle即可获得收益。

FDP的提案TP4146已经在2022年底通过NVMe正式批准。FDP也在逐步合入Linux Kernel、xNVMe等各大开源平台中（如下图），接下来就看应用软件对接的发展了。

4、结语

西部数据专家Dave Landsman在OCP会议研讨中，给出的FDP和ZNS的比较如下：

如何获得系统最大收益，系统和SSD盘间如何解耦。在系统和SSD盘片垂直整合发展过程中，这两个问题如何权衡，如何获得一个更好的平衡点。在技术界会伴随FDP和ZNS的演进，继续讨论下去。

5、参考文献

• TP4146a Flexible Data Placement, NVMe

• NVM Express Zoned Namespace Command Set Specification, NVMe

• SmartFTL SSDs, OCP Global Summit 2021

• Flash Innovation: Flexible Data Placement, OCP Global Summit 2022

• Flexible Data Placement using NVM Express Implementation Perspective, OCP Global Summit 2022

• Flexible Data Placement from the NVM Express Perspective, OCP Global Summit 2022

• Flexible Data Placement, 2023 OCP Storage Tech Talks