Background

式來管理群，可能使 hot 和 cold 資料同時在群中，因為 hot 資料一直被 hit 的緣故，

造成 cold 的資料沒有機會 flush 出去而積累在 Buffer 中，而且沒有特別留住資料較 少的群，這些資料是造成 random write 的主要原因。

我們提出一個在 Flash 儲存系統上的新 write Buffer 管理演算法稱為 Hit Statistic

（HitStat）來改善 random write 的寫入效能，藉由 Buffer 把 write requests 整理成 NFTL較容易處理的 write pattern，主要是儘量減少 random write 比例、增加 sequential write的比例。為了達到這個目的，我們同時考慮時間區域性及空間區域 性，一方面要留住最近被寫入的群來收集 sequential data，另一方面也要把含有較 少資料的群留在 Buffer 中。要充份運用 Buffer 空間避免只著重一種特性會排擠到 另一個特性的資料留在 Buffer 中，HitStat 使用能夠依不同 workload 動態調整的 Cost-Benefit Analysis來決定 Buffer replacement policy，而 Buffer 的 flush Groups 總 數在 512KB Block size、16MB Buffer、相同的 workload 下可以達到 FAB 的 54.4%，

BPLRU的 70.2%。

除了 Buffer 本身可以運用的容量，NFTL 有更大的 Log Blocks 區域，因此 HitStat 也考量到跟 NFTL 配合來運用 Buffer 和 Log Block 的空間以發揮各自的特長提昇 SSD 整體效能。對 NFTL 來說 Padding[4]過的資料可以直接取代原本舊的 Data Block；而 不做 Padding 的資料則會直接寫到 Log Block 中，但之後有回收區塊的代價。對於 什麼時機應該做 Padding，[3, 4]中沒有說明，而這卻是一個相當關鍵的問題，因為 過度的 Padding 不能利用到 Log Block 的空間，反而會導致效能下降。此篇 Paper 中我們定義一個 NFTL 的 Padding Model，HitStat 可以根據該 Model 導出的方程式，

動態決定是否對寫到 NFTL 的資料做 Padding 的動作，而實驗結果 Padding Model 可以收斂接近到最佳的 off-line Padding 設定，讓 SSD 整體效能達到最高。

接下來的章節中，第二章 Backgrond 我們會介紹 NAND Flash Memory 以及基本 的 NAND Flash Translation Layer 架構，並在 Related Work 說明既有在 Flash Storage 上的 Buffer/Cache 演算法及它們的問題；第三章先說明應用在 Flash Storage 上的 write Buffer管理方法設計時需要考量的原則，然後介紹我們提出的方法 HitStat 的 replacement policy以及 Padding Model；第四章主要說明 HitStat 的 implementation 以及 replacement policy 細節；第五章實驗會把我們的 Buffer 管理演算法 HitStat 跟 另外兩種既有方法 FAB、BPLRU 比較。首先比較 Buffer 的基本特性，接來來我們把 Buffer架在兩種基本的 NFTL 架構 BAST、FAST 上比較效能，然後再驗證我們提出的 Padding Model可以動態收斂到最佳的 off-line Padding 設定；最後第六章 Conclusion 為此篇論文做總結。

二 二 二

二、 、 、 、Background

NAND Flash Memory的組成如圖 1，主要是由多個區塊所組成，每一個區塊又 是由多個 Pages 所組成。NAND Flash Memory 的一次寫入單位（write unit）則為一 個 Page，每一個 Page 會有一個 Spare Area，可以用來儲存 User Area 中資料的 mapping資訊或者 Error Correcting Code。而刪除單位（erase unit）則為一個區塊，

即每次執行 erase 時都是以區塊為單位。NAND Flash Memory 在更新資料時與一般 的 block device 不同，如：disk，在更新某部份的資料後可直接寫回其原本的實體 位置，但是 NAND Flash Memory 無法將更改完後的資料直接寫入至該資料原本所 在的實體位置，必須再額外找空閒的 Page 寫入，此動作即稱為 outplace-update。

而原本的 data 則視為失效（invalid），但也因為如此 NAND Flash Memory 中常常會

3

存有很多 invalid data，因此 NAND Flash Memory 每隔一段時間即要清除那些 invalid data，以空出空間提供其他 data 儲存，此動作稱之為 Garbage Collection。

圖 1：Flash Memory Geometry

2.2 NAND Flash Translation Layer

由於 SSD 與 Hard Drive Disk 的硬體架構的不同，因此以往的 File Systems，如：

Ext2、Ext3、NTFS、FAT 等皆無法直接在 NAND Flash Memory 上使用，但可能在 SSD 上使用的作業系統種類相當多，會使用到的 File System 則會依所使用的作業系統 不同而不同，為了能讓 SSD 能適用於現有的 for block device 的 File System，因而有 了一個 Translation Layer：NFTL（NAND Flash Translation Layer），把自己模擬成一般 硬碟以提供上層 File System 的讀寫要求，而 NFTL 主要的功能包含(1)update policy、

(2)Address Translation、(3)Garbage Collection、(4)Wear Leveling、(5)Error Code Correction以管理整塊 NAND Flash Memory，因此 NFTL 的演算法對 SSD 的整體效能 影響很大。

討論兩種極端 mapping 方式，Page-level 和 Block-level mapping 的 NFTL。

Page-level mapping NFTL雖然可以得到很好的效能，但在 RAM 中需儲存每個 Page 從邏輯位置到實體位置的對應資訊，假設儲存一個 Page 的位置對應資訊需要 4Byte 空間、一個 Page 的大小為 4KB，一塊 16GB 的 NAND Flash Memory 就需要用掉 16MB 的 RAM 空間來儲存整個 mapping 資訊，如此大的 RAM 顯然不合乎 SSD 成本考量，

而且突然斷電後如何重建 mapping 資訊是一個問題。另一種極端的 NFTL mapping 方式，Block-level mapping NFTL 只把 Block 的 mapping 資訊存在 RAM 中，雖然需要 的 RAM 容量非常小，但即使每次只寫入少量的資料都需要抹除整個 Block 來寫入 新增料，造成大量的 overhead 所以效能非常差。

為了解決上述兩種極端 NFTL 的缺點，各種 Hybrid NFTL[5-8]架構被提出來，主 要是 mapping 方式混合了 Page-level 和 Block-level mapping。它們把 Blocks 分成兩 種：Data Blocks、Log Blocks，Data Blocks 內的資料都按邏輯位置擺放依 Block-level 方式 mapping，全部 Data Blocks 所佔的空間即為上層 File System 看到的硬碟總容 量；而 Log Blocks 則依 Page-level 方式 mapping，用來儲存新寫入的資料。當 Log Block 沒有空間可以寫入時，NFTL 需要做 Garbage Collection 的動作把部份在 Log Block 內的資料寫回其應該擺放的 Data Block 中，在 Hybrid NFTL 中我們稱之為 Merge，

主要 Merge 方式有 Switch Merge、Partial Merge 以及 Full Merge 三種。

Blocks Flash memory

…… ……

4096 bytes user area

128 bytes spare area

Pages

4

圖 2：Merge operations of Hybrid NFTL LPA為 Logical Page Address = Logical Address / Sectors per Page LBA為 Logical Block Address = Logical Address / Sectors per Block

藉由 LBA 和 LPA 我們可以查詢 NFTL 的 mapping Table 得知資料存放在 NAND Flash Memory 中的實際位置

第一種為 Switch Merge 如圖 2(a)，如果 Log Block 內的資料是依照邏輯位置按 順序寫入的，在回時空間時我們只需要更改 Block-level 的 mapping 資訊，把對應到 舊 Data Block 的實體位置改成該 Log Block 的實體位置，用 Log Block 來取代舊的 Data Block後，再對舊的 Data Block 進行抺除的動作。Switch Merge 在三種 Merge 方式 中代價最低，只需抹除一個 Block 的代價，而且這種更新方法符合 Block-level mapping的規則。

第二種為 Partial Merge 如圖 2(b)，如果 Log Block 內的資料是依照邏輯位置按 順序寫入但還未被寫滿，則我們必需要先從別的地方讀取資料把 Log Block 依序補 滿後，再做如圖 2(a)Switch Merge 的動作，因此 Partial Merge 比 Switch Merge 額外 多出搬移數個 Pages 的代價，如果原本 Log Block 內含的資料量愈少，需要搬移的 資料愈多，會造成 Partial Merge 的代價愈高。

最後一種為 Full Merge 如圖 2(c)，如果 Log Block 內的資料不是按邏輯位置順序 寫入的，則只能做 Full Merge，需要先把原本在 Data Block 和 Log Block 內的 valid 資料搬移到新的 Block 後，再更改 Data Block 的 mapping 資訊指到新的 Data Block，

再對 Log Block 和舊的 Data Block 進行抹除的動作。如果原本 Log Block 內的 valid 資料分別屬於 N 個不同的 Block，則 Full Merge 的代價一共需要 N+1 個 Blocks 抺除 和 N*每個 Block 內 Page 數量的 Pages 搬移動作，N 愈大回收的代價愈高。某些 NFTL 架構下由於 N 可能很大造成 Full Merge 的代價過高，有時候在寫入資料時會有系 統 delay 的情況。

2.3 NFTL Characteristics

雖然 Hybrid NFTL 改善了 Page-level 和 Block-level mapping NFTL 的缺點，但對於 一般用途的 write pattern，也有它們不足的地方導致效能下降，主要原因是 Full Merge的代價太高。而最近提出的 SuperBlock[6]、LAST[8]也試圖把冷、熱資料分開 以降低 Merge 的代價，但 SuperBlock 需要明確調校參數而 LAST 也要外部的 locality

Data Block

5

檢測機制使 Hybrid NFTL 的設計趨向複雜。為了說明 Hybrid NFTL 的問題，接下來我 們介紹兩種基本的 Hybrid NFTL 架構 BAST[5]、FAST[7]以及造成其效能瓶頸的原因。

BAST和 FAST 各儲存兩張 Table，一張是 Logical-to-Physical Table（L2P Table）主要 存 Block-level mapping 資訊（圖 3(a)），而另一張則是儲存 Log Blocks 的 mapping 資 訊。

圖 3：BAST and FAST Schema，LBA：Logical Block Address、PBA：Physical Block Address

參考圖 3(b)，BAST 採用的是 Block chain 的方式，當一個 Log Block 被寫完之後 則再向系統要求一個 Log Block，並會串接在原本的 Log Block 後面，若該 LBA 相當 的 hot，則該 LBA 會串上相當多的 Log Block，而做 GC 時會選擇一條 Block chain 來 回收。由於 BAST 會把屬於不同 LBA 的資料寫到不同的 Block chain 中所以不會混在 一起，因此優點是可以把交錯的 multiple sequential write streams 分開寫到不同的 Log Block中，只需代價低的 Switch Merge 或 Partial Merge；而且每一條 Block chain 中的資料都屬於同一個 LBA，這樣在做 Full Merge 的時候只需要搬移 1 個 Block 的 資料量。但缺點為，(1)對於應用在電腦儲存系統的 SSD 來說，write pattern 大多是 相當 random 的，而且只有少部份是 hot data，大部份為 cold random data 會打中 大量不同的 LBA，當 Log Block 數量不夠時，Block chains 之間會競爭有限的 Log

Data block Log blcok

NULL

Mapping info. (in RAM)

0 1 3

LBA PBA Number^Sector

0, 1, 2

Data block Log blcok PBA

(b) BAST Schema (c) FAST Schema

3

6

Thrashing，其它跟 BAST 架構相近的 NFTL 如 optimistic FTL[9]，也有 Log Block Thrashing的問題。(2)Log Block 內資料的 mapping 資訊被儲存在各個 Page 的 Spare Area中，如果要讀取某個 Page 時可能需要讀完整個 Block chain 的資料才能找到該 Page最新的 update 位置，造成讀取效能下降。

參考圖 3(c)，FAST 的 Log Block 有一個 SW Log Block（sequential write Log Block）， 其它都為 RW Log Block（random write Log Block），FAST 會試圖把 sequential write 依位置順序寫到 SW Log Block，當 SW Log Block 寫滿或者要寫另一筆新的 sequential 資料時會對 SW Log Block 做 Switch Merge 或 Partial Merge 來取代舊的 Data Block。

FAST主要的優點是可以完整的利用 Log Block 空間，沒有像 BAST 有 Log Block Thrashing的問題，但有其它的缺點，(1) 隨著 P2P 以及 Multi Thread 軟體的發展會 產生交錯的 multiple sequential write streams，FAST 會把大部份的這類資料也交雜 寫到同一個 RW Log Block 中，因為無法把這些 sequential write 分開寫到不同的 Log Block做 Switch Merge，增加大量額外的回收成本。(2)FAST 做 GC 時會回收最早寫 入的 RW Log Block，如果其中含有大量的 valid data 屬於不同的 LBA 時，需要把每 個不同 LBA 的 valid 資料搬移到新的 Block 後再對原本的 Data Block 和 Log Block 進 行抹除，造成有時候做單次 Full Merge 動作的成本相當高，導致系統 delay 的問題。

(3)由於 Log Block 是用完全的 Page-level mapping，儲存 mapping 資訊需要用到的 RAM空間比 BAST 高很多，因為使用的 RAM 空間受到限制實際上能夠運用的 Log

(3)由於 Log Block 是用完全的 Page-level mapping，儲存 mapping 資訊需要用到的 RAM空間比 BAST 高很多，因為使用的 RAM 空間受到限制實際上能夠運用的 Log