大容量 SSD（即 30TB+）帶來了一系列新的挑戰。最相關的兩個是：
- 大容量 SSD 採用高密度 NAND，例如 QLC（四層單元 NAND，每單元儲存 4 位元資料），與 TLC NAND（三層單元，每單元儲存 3 位元資料）相比，帶來更多挑戰。
- SSD 容量增長對 DRAM 與儲存容量比一般為 1:1000 的映像的本地 DRAM 記憶體提出同等增長要求。
目前，我們正面臨 1:1000 的比率不再永續的情況。但我們真的需要該比率嗎？ 為什麼比率不是 1:4000？ 或 1:8000？ 該等比率會使 DRAM 需求分別減少 4 或 8 倍。是什麼阻止我們這樣做？
本部落格探討此方法背後的思考過程，並嘗試為大容量 SSD 規劃前進方向。
首先，為什麼 DRAM 與 NAND 容量比應為 1:1000？ SSD 需要將來自系統的邏輯區塊位址 (LBA) 映射至 NAND 頁面，並需要保留所有這些位址的即時副本，以便知悉資料可以寫入或回讀到何處。LBA 大小為 4KB，而映射位址一般為 32 位元（4 位元組），因此每 4KB LBA 需要一個 4 位元組的條目；因而比率為 1:1000。請注意，極大容量需要更多條目，但為了簡單起見，我們將堅持使用該比率，原因是該比率方便推理，且不會顯著改變結果。
每個 LBA 對應一個映射條目乃最有效的粒度，因為它允許系統以盡可能低的粒度寫入（即創建映射條目）。這通常以常用於度量和比較 SSD 寫入效能和耐用性的 4KB 隨機寫入為基準。
不過，該基準可能無法長期存續。相反，如果每 4 個 LBA 或 8 個、16 個、32 個以上 LBA 對應一個映射條目呢？ 如果每 4 個 LBA（即每條目為 16KB）對應一個映射條目，我們或可節省 DRAM 大小，但如果系統需要寫入 4KB 會發生什麼情況呢？ 由於每條目為 16KB，SSD 將需讀取 16KB 頁面，修改將寫入的 4KB，然後寫回整個 16KB 頁面。這會影響效能（「讀取 16KB、修改 4KB、回寫 4KB」，而非僅「寫入 4KB」），但最重要的是，這會影響耐用性（系統寫入 4KB，但 SSD 最終會寫入 16KB 至 NAND），進而將 SSD 使用壽命縮短 4 倍。我們擔憂對耐用性要求更高的 QLC 技術會發生這種情況。耐用性對 QLC 來說至關重要！
因此，常見推理是無法改變映像粒度（或在更正式的術語中稱 Indirection Unit，「IU」），否則 SSD 使用壽命（耐用性）會嚴重下降。
儘管上述觀點皆正確，但系統是否真以 4KB 粒度寫入資料？ 頻率為何？ 我們當然可以購買一個只運行 FIO 和 4KB RW 配置文件的系統，但實際上，我們不會以這種方式使用系統。我們購買系統來運行應用程式、資料庫、檔案系統、物件儲存等。是否有任何系統使用 4KB 寫入？
我們決定進行度量。我們挑選了一組不同的應用程式基準（從 TPC-H（資料分析）到 YCSB（雲端作業）），在不同資料庫（Microsoft® SQL Server®、RocksDB、Apache Cassandra®）、不同檔案系統（EXT4、XFS）及（在若干情況下）整個軟體定義的儲存解決方案（如 Red Hat® Ceph® Storage）上運行，並度量了 4KB 寫入量及其對寫入放大（即使裝置使用壽命縮短的額外寫入）所做的貢獻。
在進行深入分析之前，我們需要討論寫入大小為何在耐用性受到損害時至關重要。
4KB 寫入將創建「寫入 16K 以修改 4K」，因而寫入放大因數（「WAF」）為 4 倍。但如果我們使用 8K 寫入呢？ 假設發生在同一 IU 內，則為「寫入 16K 以修改 8K」，因此WAF=2。結果稍微好一點。如果我們寫入 16K 呢？ 「寫入 16K 以修改 16KB」，可能不會對 WAF 造成任何影響。因此，只有少量寫入才會對 WAF 產生影響。
此外，在極少數情況下，寫入可能沒有保持一致，因此未保持一致通常會對 WAF 產生影響，但亦會隨著大小而快速減少。
下圖顯示此趨勢：
Luca 部落格 IU 圖 1：16K IU 誘導的 WAF 顯示，IO 越大，影響越小
大型寫入對 WAF 的影響最小。例如，在保持一致的情況下，256KB 可能不會產生影響（(WAF=1 倍），而在未保持一致的情況下，則影響最小（(WAF=1.06 倍）。比 4KB 寫入產生的 4 倍影響要好得多！
我們然後需要分析 SSD 的所有寫入，並觀察其是否在 IU 內保持一致，以運算每個寫入對 WAF 的貢獻。越大越好。為此，我們讓系統追蹤多個基準的 IO。我們取得 20 分鐘的樣本 （每個基準通常介於 1 億至 3 億個樣本），然後經過後處理，查看大小、IU 一致性，並計算單個 IO 對 WAF 的貢獻。
下表顯示每個尺寸貯體的 IO 數量：
Luca 部落格 IU 圖 2：來自基準測試的 WAF IU 真實資料（按 IO 計數）
如圖所示，大多數寫入都適合 4-8KB（差）的小型貯體或 256KB+（良）貯體。
如果我們應用上述 WAF 圖表，假設所有相關 IO 均未保持一致，我們會得到「最壞情況」欄報告的結果：大多數 WAF 位於 1.x 範圍內，少數位於 2.x 範圍內，而極少數位於 3.x 範圍內。比預期的 4 倍要好得多，但尚未達到切實可行之程度。
不過，並非所有 IO 都未保持一致。為什麼會這樣呢？ 為什麼現代檔案系統會建立與如此小的粒度不一致的結構？ 答：他們不會。
我們就每個基準度量了超過 1 億個 IO，並對其進行後處理，以確定它們如何與 16KB IU 保持一致。結果載於最後一欄「已度量」WAF 中。數值通常低於 5%，即 WAF >=1.05 倍，這意味著我們可以將 IU 大小增長 400%，使用 QLC NAND 和現有較小的 DRAM 技術製造大型 SSD，且使用壽命成本 >5% 而非假設所示的 400%！這些結果令人驚訝。
有人可能會說，「4KB 和 8KB 的小型寫入量很大，而且對 WAF 的貢獻分別為 400% 或 200%。由於 IO 的貢獻雖小但量多，所以合併 WAF 不應該更高嗎？」。是的，它們數量多，但貢獻小，因此負載小，而且在數量方面影響也很小。在上表中，4KB 寫入與 256KB 寫入一樣按單一寫入計數，但後者的資料量是前者的 64 倍。
如果我們根據 IO 數量（即根據每個 IO 大小和移動資料進行計算）而非 IO 計數調整上表，我們會得到以下數據：
Luca 部落格 IU 圖 3：來自基準測試的 WAF IU 真實資料（按數量計數）
正如我們所見，更密集 IO 的顏色分級現在偏向右側，這意味著大型 IO 正在移動大量資料，因此對 WAF 的貢獻較小。
最後要注意的是，並非所有 SSD 工作負載都適合這種方法。例如，最後一行表示 Ceph 儲存節點的元資料部分，其 IO 非常小，導致高 WAF=2.35 倍。大型 IU 硬碟並不適合單獨用於元資料。然而，如果我們在 Ceph（NVMe SSD 的常用方法）中混合資料和元資料，則資料的大小和數量會超過元資料的大小和數量，因此合併 WAF 所受影響最小。
我們的測試顯示，在實際的應用程式和最常見的基準測試中，轉用 16K IU 是有效的方法。我們將採取下一步行動，說服業界停止使用 FIO 對 4K RW SSD 進行基準測試，因為這不現實，而且此時不利於發展。
不同 IU 大小的影響
最明顯的後續問題之一是：為何要使用 16KB IU 大小？ 為什麼不使用 32KB 或 64KB，是否會產生影響？
這是一個非常合理的問題，需要進行具體調查，並應轉化為更具體的問題：對於任何給定基準，不同 IU 大小有何影響？
由於我們已經擁有不受 IU 大小影響的跡線，因此我們只需透過適當的模型執行這些跡線，並觀察其影響。
圖 4 顯示 IU 大小對 WAF 的影響：
Luca 部落格 IU 圖 4：IU 大小對 WAF 的影響
我們可以從圖表中排除一些結果：
- IU 大小至關重要，WAF 會隨著 IU 大小而減小。解決方案不分好壞，每個人都必須根據自己的需求和目標進行不同的權衡。
- 與我們在上面看到的許多情況一樣，WAF 減少幅度不及預期嚴重。即使在 64KB IU 的最差情況和最激進的基準測試中，減少幅度也低於 2 倍，而非令人擔憂的 16 倍
- 如前所述，元資料始終不適合大型 IU，且 IU 越大，結果就越差。
- JESD 219A 是一項基準 WAF 的業界標準配置文件，在 4KB IU 下表現不佳但可接受，而額外 3% WAF 通常可以接納，但在 IU 較大時表現異常，在 64K IU 下幾乎是 9 倍