摘要 (Abstract)

隨著資料中心與雲端運算的蓬勃發展，對於儲存系統的效能、延遲與容量需求日益嚴苛。傳統的固態硬碟 (SSD) 依賴內部複雜的快閃記憶體轉換層 (Flash Translation Layer, FTL) 來處理邏輯到物理地址的映射與垃圾回收 (Garbage Collection, GC)。然而，這種架構在面對如 RocksDB 這類日誌結構合併樹 (Log-Structured Merge-Tree, LSM-Tree) 儲存引擎時，往往會產生嚴重的雙重寫放大 (Write Amplification) 與不可預測的尾延遲 (Tail Latency)。NVMe Zoned Namespaces (ZNS) 規範的出現，為解決此一痛點提供了革命性的方案。ZNS 將儲存空間劃分為多個 Zone，並將管理權限上移至主機端，要求資料必須順序寫入。本文將深入探討 ZNS 捨棄傳統 FTL 後在 RocksDB 中的應用架構，分析其帶來的顯著效能增益，並針對 SSD 驗證工程師在面對 ZNS 設備時，剖析其測試難點與驗證策略。

1. 儲存架構的典範轉移：從 FTL 到 ZNS

1.1 傳統 FTL 的隱性成本

雖然 FTL 極大地簡化了主機端檔案系統與應用程式的開發，但也帶來了難以忽視的隱性成本。首先，維護龐大的映射表需要佔用大量的設備端 DRAM，這直接增加了 SSD 的硬體成本。其次，當 SSD 空間逐漸填滿，背景的垃圾回收機制會開始搬移有效資料以騰出可用區塊。這個過程不僅會消耗內部頻寬，導致前端應用程式的 I/O 效能產生劇烈抖動 (Performance Jitter)，更會產生寫放大效應，加速快閃記憶體的損耗。對於追求極致效能與穩定延遲的企業級應用而言，這種不可預測的尾延遲是難以接受的 。

1.2 ZNS 的崛起

為了解決傳統 FTL 帶來的效能瓶頸，NVMe 2.0 規範正式引入了 Zoned Namespaces (ZNS) 命令集 。ZNS 的核心概念是將 SSD 的邏輯地址空間劃分為多個固定大小的連續區域，稱為 Zone。與傳統的隨機讀寫模型不同，ZNS 嚴格規定每個 Zone 內的資料必須從 Write Pointer 指示的位置開始進行順序寫入 (Sequential Write Required)，但允許在已寫入的範圍內進行隨機讀取。當一個 Zone 寫滿後，必須由主機端明確發出 Zone Reset 命令，將其重置為空狀態，才能再次寫入 。

這種架構本質上是將儲存媒體的管理權限與責任從設備端轉移到了主機端 (Host-Managed)。ZNS SSD 捨棄了傳統 FTL 中複雜的邏輯物理映射與背景垃圾回收機制，僅需維護簡單的 Zone 到快閃記憶體抹除區塊 (Erase Block) 的對齊關係。這不僅大幅減少了設備端 DRAM 的需求與控制器的運算負載，更徹底消除了設備端引發的寫放大與效能抖動，為主機端軟體提供了對底層儲存媒體的極致控制力 。

2. RocksDB 與 ZNS 的完美契合：LSM-Tree 與 Zone 的共舞

2.1 RocksDB 的 LSM-Tree 架構解析

RocksDB 是一款廣泛應用於現代分散式系統與資料庫底層的高效能鍵值 (Key-Value) 儲存引擎，其核心架構基於日誌結構合併樹 (LSM-Tree)。在 LSM-Tree 的設計中，所有的寫入操作首先會被記錄到記憶體中的 MemTable 以及磁碟上的預寫日誌 (Write-Ahead Log, WAL)。當 MemTable 寫滿後，會被轉換為不可變的 Immutable MemTable，隨後被順序刷寫 (Flush) 到磁碟上，形成第一層 (L0) 的 Sorted String Table (SSTable) 檔案 。

隨著資料量增加，RocksDB 會在背景觸發 Compaction 機制，將相鄰層級的 SSTable 讀出、合併、排序後，再順序寫入到下一層。這種設計將隨機寫入轉換為批量的順序寫入，極大地優化了傳統硬碟與 SSD 的寫入效能。然而，RocksDB 的 Compaction 過程本身就會產生寫放大。當 RocksDB 運行在傳統 FTL SSD 上時，RocksDB 應用層的寫放大與 SSD 設備層的 FTL 寫放大會產生疊加效應，導致整體系統面臨嚴重的「雙重寫放大」問題 。

2.2 ZenFS：連接 RocksDB 與 ZNS 的橋樑

仔細觀察可以發現，RocksDB 寫入 SSTable 檔案的行為模式（創建檔案、持續順序追加寫入、關閉檔案成為唯讀、最終在 Compaction 後刪除檔案）與 ZNS 的 Zone 管理模型（開啟 Zone、順序寫入、關閉 Zone、重置 Zone）具有驚人的相似性。這意味著 RocksDB 天生就非常適合運行在 ZNS 設備上。

為了解鎖這項潛力，Western Digital 開發了 ZenFS，這是一個專為 RocksDB 設計的檔案系統外掛程式。ZenFS 利用 RocksDB 的 FileSystem 介面，直接將檔案映射並儲存到 ZNS 設備的實體 Zone 中，完全繞過了傳統的核心檔案系統 (如 ext4 或 xfs) 與區塊層 。

ZenFS 的一項關鍵創新是利用了 RocksDB 提供的寫入生命週期提示 (Write Lifetime Hints, WLTH)。在 LSM-Tree 中，不同層級的 SSTable 具有不同的存活時間。例如，L0 的檔案通常很快就會參與 Compaction 而被刪除，而 L6 的檔案則可能長期存在。ZenFS 根據這些提示，將具有相似生命週期的資料聚集並寫入到相同的 Zone 中。這種設計確保了當 RocksDB 刪除舊的 SSTable 時，整個 Zone 內的資料通常會同時失效。此時，ZenFS 只需要發出一個 Zone Reset 命令，就能瞬間回收整個 Zone 的空間。透過這種軟硬體協同設計，垃圾回收的責任完全交由 RocksDB 的 Compaction 機制來承擔，徹底消除了 ZNS 設備內部的 GC 負擔 。

3. ZNS 在 RocksDB 中的效能增益分析

3.1 寫放大的顯著降低

傳統 SSD 由於依賴內部 FTL 進行背景垃圾回收，無可避免地會將相同的資料在不同實體區塊間重複搬移，這使得寫放大係數 (Write Amplification Factor, WAF) 經常大於 1，甚至在重度隨機寫入負載下可能高達 3 到 4 。當 RocksDB 運行在這種設備上時，LSM-Tree 本身的 Compaction 寫放大會與 FTL 的寫放大相乘，導致整體系統寫放大急劇攀升，這不僅消耗了大量儲存頻寬，更嚴重縮短了 NAND 快閃記憶體的壽命。

透過 ZenFS 將 RocksDB 直接運行在 ZNS 設備上，這種「雙重寫放大」的困境被徹底打破。由於 ZNS 設備移除了 FTL 的垃圾回收機制，其設備層級的寫放大係數幾乎完美趨近於 1。RocksDB 應用層寫入多少資料，ZNS 設備就只會寫入多少實體資料。根據 Western Digital 的實測數據，在使用 ZenFS 與 ZNS SSD 的架構下，整體系統的寫放大相較於傳統 FTL SSD 降低了高達 4 倍 。這項改進不僅大幅延長了 SSD 的使用壽命，也意味著在相同預算下，資料中心可以部署更低耐用度 (Endurance) 規格的快閃記憶體 (如 QLC 或 PLC)，從而顯著降低總擁有成本 (Total Cost of Ownership, TCO)。

3.2 吞吐量與延遲的全面優化

除了寫放大問題，傳統 SSD 的效能抖動是資料庫管理員面臨的另一大挑戰。當 FTL 啟動背景垃圾回收時，前端主機發出的讀寫請求會被迫與背景的資料搬移操作競爭內部頻寬與快閃記憶體晶片資源，導致延遲瞬間飆高，吞吐量急劇下降。這種不可預測的尾延遲 (Tail Latency) 在要求嚴苛的線上交易處理 (Online Transaction Processing, OLTP) 系統中是致命的。

ZNS 架構透過將儲存管理權限上移，消除了設備端不可控的背景操作。RocksDB 可以透過 ZenFS 精確控制資料寫入的時間與位置，並確保讀取操作不會受到隱藏背景任務的干擾。實測結果顯示，在相同的硬體配置下，基於 ZNS 的 RocksDB 系統在 99.99% 的尾延遲表現上，相較於傳統 FTL SSD 有著數量級的改善。這使得資料庫系統能夠提供極其穩定且可預測的服務品質 (Quality of Service, QoS)，滿足企業級應用的嚴苛 SLA 要求 。

3.3 資源利用率的最大化

傳統 FTL SSD 為了維護 4KB 粒度的邏輯到物理地址映射表，通常需要配置容量約為總儲存空間 0.1% 的 DRAM。對於一塊 8TB 的 SSD，這意味著需要高達 8GB 的設備端 DRAM。這不僅增加了硬體成本，也提高了功耗與散熱設計的難度。

ZNS 設備採用了粗粒度的 Zone 管理模式。由於每個 Zone 內的資料必須順序寫入，ZNS 設備只需要記錄每個 Zone 的寫入指標 (Write Pointer) 以及 Zone 到實體抹除區塊的映射關係。這種設計將設備端所需的 DRAM 容量降低了幾個數量級，甚至使得無 DRAM (DRAM-less) 的大容量 SSD 成為可能 。此外，ZNS 架構也釋放了 SSD 內部控制器的運算資源，使其能專注於處理前端 I/O 請求，進一步提升了整體的系統吞吐量。

4. 給 SSD 驗證工程師的挑戰：ZNS 測試難點與策略

對於 SSD 驗證工程師而言，ZNS 架構的引入不僅是介面的改變，更是整個測試思維與方法的根本性轉變。傳統的 FTL SSD 測試主要集中在黑盒 (Black-Box) 測試，透過前端的 LBA 空間發送各種讀寫負載，觀察效能指標與資料一致性。然而，ZNS 將大量的儲存管理邏輯轉移到了主機端，這意味著驗證工程師必須深入理解主機端軟體 (如 RocksDB 與 ZenFS) 的行為模式，並設計針對性的測試案例。

4.1 Zone 狀態機的嚴格驗證

ZNS 規範定義了複雜的 Zone 狀態機 (Zone State Machine)，包含 Empty, Implicit Open, Explicit Open, Closed, Full, Read Only, 與 Offline 等狀態 。每個狀態都有其嚴格的轉換條件與限制。例如，當主機端向一個 Empty 的 Zone 發送寫入命令時，該 Zone 會自動轉換為 Implicit Open 狀態；當主機端發送明確的 Open Zone 命令時，則會轉換為 Explicit Open 狀態。

驗證工程師必須設計全面的測試矩陣，涵蓋所有可能的狀態轉換路徑，並驗證在異常條件下的設備行為。例如，當主機端試圖開啟超過設備支援的 Maximum Open Zones 數量時，設備是否能正確返回錯誤代碼？當向一個已經 Full 的 Zone 寫入資料時，設備是否能攔截並拒絕該操作？這些邊界條件的測試對於確保 ZNS 設備在真實環境下的穩定性至關重要。

此外，NVMe 2.0 規範引入了 Zone Append 命令，允許主機端向 Zone 中並發寫入多個資料塊，由設備端決定最終寫入的順序並返回 LBA。這種設計極大地提升了多執行緒環境下的寫入效能，但也為驗證帶來了挑戰。驗證工程師必須設計高併發的 Zone Append 測試，確保設備能正確處理並發請求，且返回的 LBA 序列與實際寫入的資料完全一致，避免資料損毀 (Data Corruption)。

4.2 系統級的垃圾回收與 Compaction 測試

在 ZNS 架構下，設備端的垃圾回收機制被移除，取而代之的是主機端的應用程式 (如 RocksDB) 負責空間回收。這意味著傳統的寫放大測試方法 (如長時間隨機寫入) 將不再適用。驗證工程師必須在主機端部署真實的應用程式堆疊 (如 ZenFS + RocksDB)，並模擬實際的工作負載進行系統級測試。

測試情境應包含 RocksDB 的長時間運行，觀察其 Compaction 過程如何觸發 Zone Reset 命令。工程師需要驗證在極端情況下，如可用 Zone 數量極少時，系統是否能穩定運行而不發生死結 (Deadlock) 或效能崩潰。此外，由於 ZenFS 會根據資料的生命週期將其分配到不同的 Zone，驗證工程師可以設計特定的資料寫入與刪除模式，測試 ZenFS 的 Zone 分配策略是否如預期運作，並驗證長期運行下的空間碎片化程度。

4.3 異常處理與邊界條件測試

ZNS 設備對於寫入操作有著嚴格的順序性與對齊要求。主機端必須確保所有的寫入操作都從 Write Pointer 指示的位置開始，且寫入的資料大小必須是邏輯區塊大小 (Logical Block Size) 的整數倍。

驗證工程師需要刻意注入錯誤的寫入模式，如未對齊寫入 (Unaligned Write)、越界寫入 (Out-of-Bounds Write)、或跳躍寫入 (Non-Sequential Write)，驗證設備是否能正確攔截並回報錯誤，同時確保 Zone 的狀態與 Write Pointer 不會因此發生異常改變。

掉電恢復 (Power Loss Protection, PLP) 是 SSD 測試中不可或缺的一環。對於 ZNS 設備，驗證工程師必須特別關注在突然斷電的情況下，Zone 狀態機與 Write Pointer 的一致性。例如，當一個 Zone 處於 Implicit Open 狀態且正在進行寫入時發生斷電，設備重啟後該 Zone 的狀態應該為何？Write Pointer 是否能準確指向最後成功寫入的位置？這些測試需要精密的硬體測試設備與複雜的測試腳本來實現。

4.4 效能基準測試 (Benchmarking) 的重新定義

傳統 SSD 的效能基準測試通常使用 fio 或 Iometer 等工具，執行 100% 的 4KB 隨機寫入測試 (常被稱為 Hero Benchmarks)，以評估 FTL 在極端壓力下的垃圾回收能力與穩態 (Steady-State) 效能 。然而，對於 ZNS 設備而言，這種測試方式毫無意義，因為 ZNS 根本不支援隨機寫入。

驗證工程師必須重新定義效能基準測試的方法論。首先，基本的吞吐量與延遲測試應改為針對多個 Zone 進行並發的順序寫入與隨機讀取。其次，更具參考價值的是端到端 (End-to-End) 的應用程式效能評估。透過部署 RocksDB 與 db_bench 等測試工具，模擬真實資料庫的讀寫混合負載 (Mixed Workloads)，並量測其 IOPS、延遲分佈 (Latency Distribution)、以及寫放大係數。

噪聲鄰居 (Noisy Neighbor) 測試在 ZNS 驗證中也扮演著重要角色。在多租戶 (Multi-Tenant) 雲端環境中，多個虛擬機器或應用程式可能同時存取同一個 ZNS 設備的不同 Namespace 或 Zone 群組。驗證工程師必須設計多客戶端並發存取的測試場景，量測在一個客戶端執行重度循序寫入時，另一個客戶端執行隨機讀取的延遲變化，以驗證設備在資源隔離與 QoS 保障方面的能力。

5. 結論與未來展望

ZNS 的出現標誌著儲存架構的一次重大典範轉移。透過將底層快閃記憶體的管理權限交還給主機端，ZNS 徹底解決了傳統 FTL SSD 在面對 RocksDB 等 LSM-Tree 儲存引擎時所遭遇的雙重寫放大與效能抖動難題。ZenFS 的創新設計更是巧妙地將 RocksDB 的應用層邏輯與 ZNS 的底層特性完美結合，展現了軟硬體協同設計的巨大潛力。

對於 SSD 驗證工程師而言，ZNS 帶來了前所未有的挑戰。傳統的黑盒測試方法已不足以應付這種主機管理的儲存架構。工程師必須具備更深厚的系統層級知識，深入理解 RocksDB、檔案系統、與 NVMe 規範之間的互動機制，並設計出涵蓋 Zone 狀態機、系統級垃圾回收、異常處理、以及真實應用效能的全面驗證策略。

隨著資料中心對於儲存效能與成本效益的要求持續攀升，ZNS 預期將在企業級儲存市場中扮演越來越關鍵的角色。未來，我們有望看到更多基於 ZNS 的創新應用與優化技術，進一步推動儲存生態系的繁榮發展。