Verification

為了驗證本篇所提出 RAPT 的正確性與可用性，本小節根據台灣 SSD 開發 廠商提供的韌體演算法和硬體架構與其真實產品做比較。首先針對單一 Chip 的 韌體演算法比較，採用的美光科技（Micron）的 NAND Flash，規格為 MLC，FTL 則採用加入 pending 機制的 Block Level，為了觀察驗證的細節，使用 HD tune [26]

工具記錄每一筆 request 的回傳資訊，藉此針對細部的回應時間做比較，比較結 果就讀取和寫入兩種行為討論，又分為 64KB 大資料和 4KB 以下小資料的存取。

圖 28 為讀取行為的驗證結果，其中大檔案存取的不規律跳動曲線是讀取行 為跨越 block 時會去重新載入 RAM 中的 mapping 資訊的原因，此項已加入模擬 考量，圖中虛線部分表示模擬行為，實線部分為實際 SSD 行為，可見讀取的趨 勢兩者大致相同，但模擬時間約略少實際時間 1 ms，這段誤差來源主要是 Flash bus delay 的傳輸，如同 5.1.1 所述，其影響因素很多，因此要確認讀寫的瓶頸往 往需要煩雜的交叉比對驗證，暫時不在本篇的討論範圍內。

- 32 - 0

5 10

Response (ms)

Large read Sequence s

Small read Sequence

sim 同，其中因為模擬過程沒有根據資料搬移成本考量是要做 pending 或者做 merge，

與實作方式略有不同所以造成部分曲線不雷同。綜合而言，讀取行為的模擬時間

Large write Sequence simsrc

Small write Sequence sim

src

b、小檔案存取（4KB）

圖 29、韌體演算法寫入驗證

除了針對單一 Chip 的 FTL 驗證，本節也驗證在不同硬體架構下 RAPT 的表 現是否符合預期，其採用的 FTL 以 KAST 為基礎做變化，Over provisioning 將近 15%，使用 MLC 的 Flash chip，並且採用本篇所提及的平行演算法。表 3 就兩種 不同的架構測試，使用 IOmeter 純隨機的 workload 寫入，Time 表示測試的時間 長短，分為 3 分鐘和 30 分鐘的測試，結果以 IOPS 呈現，其中前 3 分鐘大部分 的資料被 spare block 吸收掉，因此效能會表現得較好，如表所示，在僅有 2-Plane 的架構下模擬與實際差異不大，誤差約 5%，但當架構變複雜以後誤差就上升到 15%，因為高平行架構的模擬需要考慮韌體與硬體實作的細節，而少部分細部資 訊是本篇無法從廠商取得的。

- 33 -

表 3、硬體架構寫入驗證

Time Source IOPS Simulation IOPS 1-Channel 1-Interleave 2-Plane 30 min 250 262 4-Channel 4-Interleave 2-Plane 3 min 1039 894 4-Channel 4-Interleave 2-Plane 30 min 474 554

本節的測試包含很多影響因素，像是未知的韌體錯誤、ECC 造成的重新讀 寫時間、RAM 的存取以及未知的硬體溝通時間等，所以數據的誤差仍然存在，

但也可以由驗證中得知，所有模擬結果與實際差異的趨勢相同且符合預期，所以 RAPT 對於 SSD 的測試與設計是有效的，未來將與本計畫開發的真實 SSD 做比 較，可以得到更完整且正確的驗證資訊。

- 34 - 5.2 Environment

本篇除了討論 SSD 設計的概念並開發一套快速模擬工具，也針對 SSD 韌體 演算法和硬體架構作一連串的探討，有關 SSD 的討論已持續好幾年，近年的研 究不管是 FTL 還是硬體架構的同質性都越來越高，因此本篇一方面歸納整理以 往的方法，一方面根據這些方法結論表現最好的韌體與硬體組合，也希望透過這 些研究給予 SSD 的設計更多啟發，同時從這一章也可以驗證 RAPT 的功能性與 準確度。

實驗部分採用之各項參數如表 4，Flash chip 規格取自 Samsung NAND K9XXG08UXA 和 K9XXG08UXM，分別代表 SLC 與 MLC，傳輸速度方面假設 DMA 與 Bus 的延遲很短，因此瓶頸為 Flash chip 內部 register 的讀寫（換算後約 40 MB/s），另外，所有 Log-based 的 FTL 在沒有特別說明的情況下一律以 workload 大小的 5 %作為閒置空間也就是 spare size。未計的時間參數的部分包含 RAM 以 及 page spare area 的存取，還有處理器下指令（Command）的延遲，由於這些時 間十分微小，平均每一個 request 影響不到 1μs，所以忽略與否並不會干涉結果。

表 4、實驗參數設定

SLC MLC

Page / Block size 2 KB / 128 KB 4 KB / 512 KB Read latency 25 μs 60 μs Write latency 200 μs 800 μs Erase latency 1500 μs

Data transfer delay 25 ns/byte Spare block area 5 %

SSD 一般用於高效能要求的系統，本篇假設實驗對象的 SSD 為個人用儲存 系統和伺服器儲存系統，個人用的儲存系統像是筆記型電腦或 PDA 等，因為個 人使用習慣大多不一致，因此可能的存取行為較混雜，包含較多的高頻率存取資 料（Hot Data）和眾多的隨機（Random）與循序（Sequential）資料，本篇以使 用者在 Windows XP 和 Ubuntu 9.04 作業系統上的行為表示，兩者分別採用 Diskmon [19]和 Blktrace [20]擷取約一個月的存取行為。而伺服器系統就是資料 庫系統，其種類繁多，但共同特徵是存取行為遠比個人用系統極端，本篇簡單分 為隨機與循序兩種，前者是採用 IOmeter [21]產生的小 request 隨機存取行為，後 者是採用 Diskmon 擷取使用者在 Windows 上對多媒體影音的存取行為。

因為讀取的動作較單純，不會影響 GC 等機制，所以本篇僅討論寫入的行 為，上述的 workload 也都是單純的寫入，表 5 是其詳細分析資料，其中 Windows

- 35 -

和 Ubuntu 的表現十分相近，都具有固定量的隨機、循序資料和 hot data，不相同 的是 Windows 的 request 對齊（Align）的比例較高，也就是說每次是由 page 中 第一個 sector 開始寫入的 request 較多，這樣可以使空間利用度較高，FTL 在處 理時也會比較容易。此外由於 Ubuntu 與 Windows 的檔案系統（File System）不 一樣，因此 Ubuntu 的 request 都是 4 KB 的倍數，且最大 request 可以到達 512 KB，

而 Windows 只有 64 KB。至於 IOmeter 和 Multimedia 都是低頻率存取的資料（Cold Data），但前者包含的都是 4 KB 大小的隨機資料，而後者大部分都是 64 KB 大 小的循序資料。

表 5、Workload 分析結果

Windows Ubuntu IOmeter Multimedia Disk size 40 GB 30 GB 15 GB 20 GB Data transferred 81.19 GB 70.96 GB 18.05 GB 20.16 GB Request count 7,428,600 3,718,295 4,731,296 352,353 Avg. request size 11.46 KB 20.01 KB 4 KB 60 KB Sequential ratio 39.45 % 28.56 % 0.61 % 93.99 % Rewrite ratio 72.77 % 57.32 % 2.25 % 9.24 % Align 2K 22.49 % 0 % 24.69 % 98.78 % Align 4K 5.45 % 0 % 12.35 % 96.91 %

假設系統在飽和狀態（Warm-Up State），SSD 中的邏輯位址填滿資料，但備 用區域是空的，而所採用 workload 的資料量都可以填滿備用區域，因此所有的 測試將是有效的，同時假設所有的 workload 的 request 為連續不斷，因此 Buffer 不會有閒置。接下來數據的效能都以 IOPS（IO per Second）呈現，每個 workload 的 IO 大小如表 5 的 Avg. request size。

- 36 - 5.3 Exploration of FTL Design

在 SSD 韌體中最重要的就是 FTL 的設計，其 Address Mapping 方法影響 RAM 的需求量，也就決定了成本多寡，Garbage Collection 影響效能，而 Wear Leveling 則影響 SSD 的壽命，應此本節針對 FTL 各種設計的效能表現做討論，其中多數 Wear Leveling 的實作對效能幫助不大，且其方法與種類過於複雜，並不是本篇 討論的重點，因此暫不將其列入討論。本節分為四個小節，第一小節是關於 Address Mapping 的議題，根據位址對應的大小分別討論 Block Level、Page Level 和 Log-based 三種 FTL，第二小節討論各種 FTL 的循序優化機制，第三小節再針 對 Log-based FTL 的 data block 與 log block 對應特性做討論，最後一小節討論備 用空間大小對 FTL 的影響，同時結論各 FTL 的效能。

5.3.1 Address Mapping Granularities

關於 FTL 的討論首先會想到位址轉換，由 Host 端進來的 request 的位址稱為 邏輯位址（Logical Address），由於 Flash 的 Erase-Before-Write 特性，通常會將 request 寫入到不同的位址，也就是實體位址（Physical Address），而為了知道哪 筆邏輯位址的資料存在哪個實體位址，必須要建立一個對應表（Mapping Table）， 此表暫存在 RAM 中，若 mapping 的位址單位越小，要存的資訊就越多，需要的 RAM 就越大，SSD 的實作成本也會越高，稱為微對應（Fined-Grained Mapping）， 相 反的 mapping 單 位 越大就 越省 RAM， 但 效能也 會比較 差，稱為 廣對應

（Coarse-Grained Mapping），前者以 Page Level 為代表，後者以 Block Level 為代 表，此處簡稱 PL 和 BL，而混合這兩者的 FTL 則稱為 Log-based FTL，這裡討論 的 Log-based FTL 以 BAST 和 FAST 為例。

圖 30 是各 FTL 的效能表現，其中 BL 因為每一次寫入就必須搬移整個 block 的資料，所以表現最差。而 BAST 除了在 Multimedia 與 FAST 差不多，其他的 workload 都遜於 FAST，那是因為其他的 workload 較多隨機存取，因此 BAST 容 易發生此處配置 log block 後另一處又必須再配置，而導致 spare block 永遠不夠 用的情況，這種情形稱為 Block Threshing。此處 PL 的作法是直接將資料寫入空 的 page 中，而 GC 時則用貪婪法（Greedy Method）挑選有效資料最少的 block 回收，同時也加入簡單的冷熱資料分離機制，但 PL 在 Ubuntu 的行為下還是輸 給 FAST，這是參雜許多 hot 和 cold 資料的關係，cold page 在 GC 時會被搬到新 的 block 和其他 hot page 混合在一起，造成每次 GC 挑中回收的 block 都還是要 搬移許多 cold page，而這種情形會受到 block 大小的影響，MLC 的 block 較大，

所以混合的情況也會較嚴重，因此表示本篇所實作的冷熱資料分離（Hot-Cold Separation）方法仍有待改進，但可以從隨機資料的寫入看出 PL 的潛力。其次 PL 的 Mapping table 十分佔用 RAM，因此近幾年也提出很多方法討論如何在有

- 37 -

限的 RAM 實現 PL 的效能，像是第二章提到的 Super Block 以及 DFTL [22]等都 很具代表性。

圖 30、不同 mapping 單位的 FTL 效能

綜合而言，Fined-grained mapping 的 FTL 可以減少空間的浪費和額外的有效 資料搬移動作，因此在各種存取行為下表現較好，但其大量 RAM 的消耗使得目 前大部分 SSD 都採用 Log-based 的 FTL，至於 Coarse-grained mapping 的 FTL 若 加上特殊的機制則可以有效利用於隨機資料的存取，將在下一小節討論。

5.3.2 Sequiantiql Optimal

Block Level 和 Log-based 的 FTL 各自有針對循序存取的優化方法。BL 的方 法稱為延遲抹除（Pending），BL 每一次寫入都要將 block 中其餘 page 搬移到新 block 的動作對效能破壞很大，有時候明明是可以接續寫的資料，卻還是要依循 搬移、寫入、erase 的流程，因此 pending 就是紀錄上一次寫入的 block 位址和寫 到的 page，若下一次要寫的 page 在同一個 block 且在上次寫入的 page 之後，則 搬移資料到這次要寫的 page 再寫入，而不需要花費多餘的搬移或 erase 動作。

Log-based 的 FTL 在 GC 時必須做 merge，而 merge 又分為直接替換（Switch Merge）、部分搬移（Partial Merge）和全數搬移（Full Merge）三種，其中 switch merge 是指要 GC 的 log block 內的每一個 page 及其相對位址都與 data block 內的 相同，因此可以直接以其替換原本的 data block，而 partial merge 就是只有前段

Log-based 的 FTL 在 GC 時必須做 merge，而 merge 又分為直接替換（Switch Merge）、部分搬移（Partial Merge）和全數搬移（Full Merge）三種，其中 switch merge 是指要 GC 的 log block 內的每一個 page 及其相對位址都與 data block 內的 相同，因此可以直接以其替換原本的 data block，而 partial merge 就是只有前段