三、 Low-Cost LBA-Based Wear-Leveling Algorithm
3.4 Implementation Issues
圖 12：Priority Queue with LRU Replacement Policy on LBA
3.4 Implementation Issues
我們的 wear leveling 是一種 low‐cost 的 wear leveling algorithm，希望能盡可能 的減少 RAM 的使用空間，因此我們希望在現有的架構下，利用其他已知的資訊來 達到相同的效果，並捨棄某些重覆的資訊，如此可減少 RAM 的使用空間。在此章 節討論幾種方法取代用來尋找 Cold Data 的 Bitmap，可省下一個 Bitmap 的空間，
亦可尋找到 Cold Data，完成 wear leveling。
在前面的章節中的 wear leveling 中所提到的 bitmap，主要用途是用來尋找 Cold Data，Cold Data 的特性即為不常 Update，利用此特性我們覺得可以使用其他現有 的資訊來尋找 Cold Data，而不使用 Bitmap。而在現有的資訊中，我們發現有三種 方式可以搜尋到 Cold Data：(1)使用 Priority Queue 來判斷是否為 Cold，(2)依序檢查 每一個 LBA 的 Block Chain，若長度為零（即只有 Data Block），則表示為 Cold Data，
(3)利用 Bitmap for Garbage Collection，此 Bitmap 為當該 LBA 有 write 時，則 Bit 設 為 1，未 write 則 Bit 為 0，因此當 Bit 為 0 時，其 Data 必為 Cold Data。這幾種尋找 Cold Data 的方法雖然比不上使用 Bitmap 精確，但不失為減少 RAM 使用空間的一 種方法。
第一種方式是以 Priority Queue 來判斷 Data 是否為 Cold。我們的 Priority Queue 主要是用來儲存 Hot LBA，因此不在 Priority Queue 的通常可以當作是 Cold LBA，亦 即 Cold Data。我們使用 Round‐Robin 的方式從頭一一的檢查每一個實體區塊，當 檢查一個實體區塊時找到其所配置的 LBA，再查詢 LBA 是否存在 Priority Queue 中，
若不存在，則表示為 Cold LBA，表示實體區塊內所儲存的為 Cold Data。當 wear leveling 執行時，利用此方式挑選 Cold Data，再將 Cold Data 移到由 Priority Queue 所挑選出來的 Old Block。此種方式雖然節省了一個 Bitmap，但是卻額外多出了 Priority Queue 的搜尋時間，可能會拖慢一些系統速度。在當 Priority Queue 不夠大 時，會無法記錄到所有的 Hot LBA，因此也會造成在判斷是否為 Cold Data 時發生誤 判的情況。
第二種方式是利用 Block Chain 的長度來判斷是否為 Cold Data 的依據。當 Block Chain 長度為 0 時(該 Block Chain 無 Log Block)，表示其對應的 LBA 幾乎未曾有 Update，即該 LBA 為 Cold LBA，其 Data 為 Cold Data。當 wear leveling 執行後，利 用 Priority Queue 挑選出 Old Block，再以 Round‐Robin 的方式從頭開始檢查每一個 LBA 的 Block Chain 長度，當檢查到 Block Chain 長度為 0 的 LBA，則視為 Cold Data，
將該 LBA 中的 Data 移到 Old Block 中，而 Old Block 則變成該 LBA 的新 Data Block。
此種方式雖然可尋找到 Cold Data，但是仍會有許多 Cold Data 會被其視為非 Cold Data，因為許多的 LBA 可能會有些許數量的 Update，但可能一、兩次 Update 即不 再 Update 了，但是 Block Chain 的長度卻不為 0。這種 Data 亦為 Cold Data，但透
15
過此方式在判斷是否為 Cold Data 的過程中，會將其誤判為非 Cold Data。
第三種方式則是利用前面章節所提到的 Garbage Collection 所使用的 Bitmap，
當 Bitmap 中的 bit 為 0，則表示其對應的 LBA 未曾被 Update，反之則曾經被 Update。
Wear‐leveling 運作時要尋找 Cold Data 則以 Round‐Robin 的方式從 LBA 0 開始，檢查 LBA 對應的 Bit 是否為 0，若為 0 則表示為 Cold LBA，亦為 Cold Data，而此 LBA 的 Block Chain 未必為 0，因此我們先將該 LBA 的 Block Chain 中有效的 Data 移到 Old Block 中，再把 Block Chain 回收起，Old Block 則成為該 LBA 的新的 Data Block。這 種方式如前一種方式的缺點一樣，即是會將 Cold Data 誤判會非 Cold Data 的情形發 生。
這三種方式皆可取代 Bitmap 而達到搜尋到 Cold Data 的目的，省下 RAM 空間 的耗用，可參考 Section 4.7 的數據，這幾種方式取代 Bitmap 後的效果與使用 Bitmap 並不會差太多。
3.5 How to store erase cycle of all blocks
我們的 Wear leveling algorithm 需要計算 Average Erase Cycle 以及得知實體區塊 的 Actual Erase Cycle，因此在我們的 wear leveling 使用的預設前提之下，是會知道 所有實體區塊的 erase cycle，即每一個實體區塊的 Actual Erase Cycle 皆可查詢到，
並可計算出 Average Erase Cycle。我們需要把所有實體區塊的 Erase Cycle 儲存在 Flash Memory 上，而如何將實體區塊的 Erase Cycle 儲存起來，可利用現有的方法 達到儲存的目的。
(1)利用一個實體區塊儲存所有實體區塊的 Erase Cycle，會先在 RAM 中記錄，
然後定時更新至實體區塊中，(2)在 M‐System 的 NFTL 中，使用的方式即是每一個 實體區塊的 Erase Cycle 存放在該實體區塊中第一個 Page 的 Spare Area 中，需要支 援 Partial Page Write 的 NAND Flash Memory 才行，但是現在大部份的 NAND Flash Memory 皆不支援 Partial Page Write，因此可行性低，(3)將每一個實體區塊的 Erase Cycle 固定存放在該區塊的第一個 Page 中，此方式會浪費掉每一個實體區塊的一個 Page，(4)同方法(2)，但不需要 Partial Page Write 的支援，在回收實體區塊時不將實 體區塊抹除，而直接回收到系統中，待系統分配出可用實體區塊時再從該區塊第 一個 Page 的 Spare Area 讀出 Erase Cycle，再抺除實體區塊，將 Data 寫入該實體區 塊時一并將最新的 Erase cycle 寫入第一個 Page 的 Spare Area，如此即可記錄正確 的 Erase cycle。
四、Experimental Results
4.1 Environment set up
在我們的實驗中，所使用的 NAND Flash Memory 規格如表 3，所有的實驗皆在 此 NAND Flash Memory 的規格下完成。在實驗測試的過程中，我們會在 Windows XP 上蒐集為期一個月中 Operating System 對 Hard Disk 所下 Write/Read 指令，將這些 指令對各個 wear leveling algorithm 進行測試。
我們的 wear leveling algorithm 主要比較對像為 Random wear leveling[13]、Static wear leveling[8]以及 Group‐Based wear leveling[7]。Random wear leveling 即每 Threshold 次的 Garbage Collection 即 Random 挑選 k 個實體區塊來 Erase。，這幾種 wear leveling algorithm 皆與我們的 wear leveling algorithm 建置在相同的 NFTL 架構 下，以便在同等條件下比較出各 wear leveling 的效果。在實驗中，我們會測試每一
16
個 wear leveling algorithm 的 standard deviation 和 mean，其中 standard deviation 是 用來測試 wear leveling 的效果如何，磨損程度是否平均，standard deviation 愈小則 效果愈好，表示抺損愈平均，mean 則表示 wear leveling 所花費之成本，mean 愈 高則成本愈高。
我們會在不同數量的 Spare Block 情況下測試各 wear leveling algorithm，觀察 當系統可用區塊減少，對 wear leveling algorithm 的影響。而在本篇提出的 wear leveling 會測試在不同的 Spare Block 數、Priority Queue Size 以及 Threshold 不同之 下的數據比較，以得知在何種情況下、哪種條件的 wear leveling 效果較好，或者 Overhead 較低。
表 3：NAND Flash Memory 規格
Page Size 2K Bytes Block Size 128K Bytes Pages Per Block 64
Total Physical Blocks 172,032 Total Size 20G Bytes
4.2 Realistic Workload Analysis & NFTL Garbage Collection Policy Analysis
4.2.1 Realistic Workload Analysis
我們在 Windows XP 上擷取 Operating System 對 Hard Disk 所下的 Write/Read 指 令，為期一個月，然後針對擷取下來的資訊做分析。分析結果如表 4，對同一個 LBA 寫入次數愈多的數量愈少，反之則愈多，表示大部份的 Data 都僅寫入數次，即 Cold Data 較多，只有少數的 Data 寫入次數較高，即 Hot Data 較少，可知 Hot Data 的數 量遠少於 Cold Data 的數量。因此我們的 lazy wear leveling algorithm 以 Hot Data 為 主要對像，因為它的數量較少，可用較少的 RAM Space 即可記錄大部份的 Hot Data，以表四來觀察，若我們認為對同一 LBA 寫入次數超過 100 即為 Hot Data，則 我們只用一個大小為 2048 的 Priority Queue 即可記錄了所有的 Hot Data，我們的 Priority Queue Size 也是以此分析決定的。
表 4：Disk trace 分析 Total Writes(次數)：1,772,339
範圍(次數) LBA 個數
0~100 162,208
101~1000 1,505
1001~10000 119
10001~30000 6
>=30001 2
Total：163,840 個 LBAs
4.2.2 NFTL Garbage Collection Policy Analysis
此節要討論 NFTL Garbage Collection Policy，在 Section 3.1.2 所討論的 Garbage Collection Policy 中的兩種方法：一個為 Greedy Garbage Collection，另一個則為 Bitmap Garbage Collection。而我們在這裡測試了下面幾個 Garbage Collection Policy：
17
P1：Bitmap Garbage Collection P2：Greedy Garbage Collection P3：Recycle overrun block chain
表 5 為使用上列三種方法以及混合使用所產生的 Total Erase cycles 及 Average Erase cycles。所表可知當使用 P2 時，會因為區塊被 Cold Data 佔據，使得系統可用實體 區塊大幅減少，造成 Garbage Collection 相當頻繁，因而使得 Total Erase cycles 相當 高，即使加上 P3 後效果亦無改善，大部份長的 Block Chain 都會被 Garbage Collection 所回收，比較不會因 overrun 而回收。而 P1 的主要特點為回收被 Cold Data 佔據的 區塊，效果比 P2 改善甚多，與 P1+P3 的差別在於 P1 中的 Block Chain 長度不限制，
因此 Hot Data 的 Block Chain 會長得相當長，亦耗用不少的區塊，在加上 P3 的 Policy 後亦可改善此缺點，效果上有所改善，可知在 Garbage Collection Policy 的設計上，
應該回收的對象應該為被 Cold Data 佔據的 Block Chain，而非最長的 Block Chain。
表 5：Garbage Collection Policy 比較
Total Erase cycles Average Erase cycles
P1 485,100 2.82
P2 1,596,387 9.28
P1+P3 416,418 2.42
P2+P3 1,596,323 9.28
此表為 P1、P2、P3、P1+P3 以及 P2+P3 的實際 Total Erase cycles，可觀察出 P2 造成的 overhead 相當得高，因 為它無法真正回有有效的區塊，因此造成 Garbage Collection 相當頻繁且 overhead 高。在使用 P1 後 Total erase cycles 降低 P2 的約四分之一。
4.3 PBA‐Based Lazy Wear‐Leveling v.s. LBA‐Based Lazy Wear‐Leveling
在此節中針對我們的 Lazy wear leveling 中 Priority Queue 的對像不同做比較，一個為 PBA‐Based 的，利用 Priority Queue 記錄最近常常被 Erase 的區塊 PBA。另一 個則為 LBA‐Based，利用 Priority Queue 記錄最近常常 Write 的 LBA。在圖 13 中，
可看出每一個 Threshold 的 Standard Deviation 在 Priority Queue on LBA 皆比 Priority Queue on PBA 低，並且在 Mean 相同時，Priority Queue on LBA 的 Standard Deviation 亦較低，wear leveling 效果較好。如 Priority Queue on PBA 在 TH4 時與 Priority Queue on LBA 在 TH12 時的 Mean 皆約為 24.3，但 Priority Queue on LBA 的 Standard Deviation 約為 14，Priority Queue on PBA 的 Standard Deviation 約為 17，Priority Queue on LBA 的效果優於 Priority Queue on PBA。
Priority Queue on PBA 效果較 Priority Queue on LBA 差，主要原因為在 Section 3.3 中所提到的使用 PBA‐Based 時會有一些問題，因此效果較 LBA‐Based 的差。
18
圖 13：Priority Queue on PBA v.s. Priority Queue on LBA
4.4 The effect of priority queue size, threshold
在此節我們說明不同的 Priority Queue Size 以及不同的 Threshold 所造成的影 響。在實驗中的 Priority Queue Size 分別是 2048、1024 和 512 和 Threshold 分別為 4、8、12、14、16 的情形下的 wear leveling 效果。其結果為圖十，觀察出不管 Spare Block 個數為多少，Priority Queue Size 愈大，其 Standard Deviation 愈低，效果也愈 好。主要是因為 Priority Queue Size 愈大，其擷取到的 Hot Data 愈精確，比較不會 有將 Hot Data 誤判為 Cold Data 的情形。Threshold 愈大則 Standard Deviation 也愈 高，反之則愈低。Threshold 主要是用來當作一個門檻值，即當一個區塊的 Erase Cycle 高於平均 Erase Cycle 加上 Threshold 即認為是 Old Block。Threshold 愈低，表示愈多 區塊會被視為 Old Block 而執行 wear leveling 將 Cold Data 放入 Old Block 中，使得 大部份區塊的 Erase Cycle 的差距範圍大概在 0 至 Threshold 之內，效果較好，但也 使得一直執行 wear leveling 將 Cold Data 放到 Old Block 中，雖然效果好，但是成本 會相對的提高。
在圖 14 中，可看出 Threshold 愈低，mean 愈高，即成本較高。Threshold 愈低 表示所執行的 wear leveling 次數愈多，因此效果也較好（即 Standard Deviation 愈 低），但所花費的成本也較高（即 mean 愈高）。Wear leveling 次數愈多會使得每個 區塊的磨損程度愈平均，但也因為 wear leveling 次數過多，會花費額外搬移資料及 磨損區塊的成本更多，因此 mean 亦會愈高。
圖 14：LBA‐Based wear leveling 在不同的 Priority Queue Size 與 Threshold 的比較。
圖 14：LBA‐Based wear leveling 在不同的 Priority Queue Size 與 Threshold 的比較。