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