嵌入式儲存系統效能評估

國

立

交

通

大

學

資訊科學與工程研究所

碩

士

論

文

嵌 入 式 儲 存 系 統 效 能 評 估

Benchmarking Embedded storage system

研 究 生：曾士豪

指導教授：張立平 教授

嵌入式儲存系統效能評估

Benchmarking Embedded storage system

研 究 生：曾士豪 Student：Shi-Hao Tzeng

指導教授：張立平 Advisor：Li-Pin Chang

國 立 交 通 大 學

資 訊 科 學 與 工 程 研 究 所

碩 士 論 文

A Thesis

Submitted to Institute of Computer Science and Engineering College of Computer Science

National Chiao Tung University in partial Fulfillment of the Requirements

for the Degree of Master

in

Computer and Information Science

June 2007

Hsinchu, Taiwan, Republic of China

嵌入式儲存系統效能評估

學生：曾士豪

指導教授：張立平

國立交通大學 資訊工程 學系﹙資訊科學與工程 研究所﹚碩士班

摘

要

快閃記憶體已經成為嵌入式計算環境的主流儲存媒體。拜嵌入式處理器效能長 足進步之賜，處理大量資料已經不是桌上型電腦或者大型主機的專利了。快閃記憶體本 身有著相當獨特的物理特性，因此以往設計給磁碟的檔案系統並不能直接使用在快閃記 憶體上。也由於這個原因，對以磁碟為基礎所設計的效能評比與工具，並不能反映一個 針對快閃記憶體設計的檔案系統的良莠。因此，本論文著眼於如何針對以快閃記憶體為 基礎的檔案系統做一有系統的評比測試，目的是為了呈現以往測試評比工具所不能顯現 的效能差距。這樣的結果，除了可建議使用者在某些工作負荷下應該用哪一種檔案系 統，更重要的是，避免選擇在該工作負荷下效能不彰的檔案系統。

關鍵字:

Filesystem Benchmark, embedded storage, flash memory, Garbage collection, Wear-leveling, JFFS2, YAFFS, NFTL

Benchmarking Embedded Storage System

student：Shi-Hao Tzeng

Advisors：Li-Pin Chang

Department﹙Institute of Computer Science and Engineering﹚of Computer

Science

National Chiao Tung University

ABSTRACT

Flash memory has become a crucial component in building embedded computing systems. With the dramatic improvement of the computing power of embedded processors, embedded computers is now capable of processing massive data. In past work, the benchmark of disk-based file systems has been widely studied. However, because of the very different physical characteristics of flash memory, these existing benchmark suites are not suitable to evaluate flash-memory-based file systems. This work is motivated by the needs for the benchmark tools for embedded file systems. Our objectives are to reveal the how efficient the existing flash-memory file systems deal with the fundamental issues of flash-memory

management. The benchmark results provide users valuable information regarding not only to choose a good solution in their embedded computers but also to avoid a poorly performing approach under certain workloads.

Key word: Filesystem Benchmark, embedded storage, flash memory, Garbage collection, Wear-leveling, JFFS2, YAFFS, NFTL

誌

謝

終於抵達寫致謝詞的這一刻，這意味著研究所生涯即將正式的畫上句

點，回顧兩年來的經歷，內心充滿幸福與感謝，首先誠摯的感謝指導教授

張立平老師，老師悉心的教導使我得以了解嵌入式系統的深奧，不時的討

論並指點我正確的方向，使我在這些年中獲益匪淺。因為有你的體諒及幫

忙，使得本論文能夠更完整而嚴謹。

二年多的求學生涯裡，讓我學習了不少新的知識和待人接物的方法，非

常感謝每個老師的敦敦教悔，而且勤而不懈的教導我，讓我能夠一路走來

都很順利。

再來，感謝在這段期間，游仕宏、張譽璸、黎光仁、杜俊達同學的幫忙，

使得我能順利走過這兩年。實驗室的黃千庭、許辰暉、林松德、鄭家明、

許惠茹…等學弟妹們，當然也不能忘記與你們相處的日子。還有各位在新

竹一起奮鬥的“捧油＂們，在這非常感謝小螞蟻、sfancy、老大、小傅、

小卷、kayla 以及應數所的球友們和親愛的室友們，你/妳們的幫忙、陪伴

及搞笑我深刻地銘記在心，由衷感謝各位的相助。謝謝！

研究口試期間，感謝羅習五老師、陳雅淑老師不辭辛勞細心審閱，不

僅給予我指導，並且提供寶貴的建議，使我的論文內容可以更臻完善， 在

此由衷的感謝。

感謝系上諸位老師在各學科領域的熱心指導，讓我增進各項知識範疇，

在此一併致上最高謝意。

最後感謝我摯愛的雙親和家人，因為他們的支持，才有此篇論文的產生。

目

錄

中文提要

………

i

英文提要

………

ii

誌謝

………

iii

目錄

………

iv

表目錄

………

vii

圖目錄

………

viii

一、

Introduction………

1

二、

Motivation & Related work ………

3

三、

Fundamental Management Issues of Flash-Memory Storage

Systems………

6

3.1

Flash-Memory Physical Geometry ………

6

3.2

Flash Memory in Storage Hierarchy………

7

3.3

Address translation ………

8

3.4

Garbage Collection (GC)………

10

3.5

Wear-Leveling………

12

四、

Flash-Memory-Based File-System Benchmarks………

14

4.1

Flash-Space Utilization………

14

4.1.1 Performance issues ………

14

4.1.1.1 User data & Metadata of File system ………

14

4.1.1.2 Fragment ………

15

4.1.1.3 Mapping size effect ………

15

4.1.2 File-System Implementations ………

16

4.1.2.1 JFFS2 ………

17

4.1.2.2 YAFFS………

18

4.1.2.3 NFTL………

18

4.2

RAM-Space Requirements ………

19

4.2.1 Performance issues ………

20

4.2.1.1 Address translation ………

20

4.2.2.2 File-system management structure ………

20

4.2.2.3 Directory hierarchy structure ………

21

4.2.2 File-System Implementations ………

21

4.2.2.1 JFFS2 ………

21

4.2.2.2 YAFFS………

23

4.2.2.3 NFTL………

24

4.3

Garbage Collection ………

24

4.3.1 Performance issues ………

25

4.3.1.1 Hot data and Cold data………

25

4.3.1.3 Garbage-collection policy………

25

4.3.2 File-System Implementations ………

26

4.3.2.1 JFFS2 ………

26

4.3.2.2 YAFFS………

27

4.3.2.3 NFTL………

28

4.4

Wear-Leveling………

29

4.4.1 Performance issues ………

29

4.4.2 File-System Implementations ………

30

4.4.2.1 JFFS2 ………

30

4.4.2.2 YAFFS, NFTL………

30

五、

Experiment Design and Experiment Result

………

30

5.1

Flash-Space Utilization………

31

5.1.1 Experimental Setup and Performance Metrics………

31

5.1.2. Test plans………

31

5.1.2.1 Black-Box test………

32

5.1.2.2 White-Box test………

32

5.1.3 Numerical Result………

34

5.1.3.1 Black-Box test………

34

5.1.3.2 White-Box test………

35

5.2

RAM-space Requirements………

39

5.2.1 Experimental Setup and Performance Metrics………

39

5.2.2. Test plans………

39

5.2.2.1 Black-Box test………

39

5.2.2.2 White-Box test………

39

5.2.3 Numerical Result………

40

5.2.3.1 Black-Box test………

40

5.2.3.2 White-Box test………

41

5.3

Garbage Collection………

44

5.3.1 Experimental Setup and Performance Metrics………

44

5.3.2. Test plans………

44

5.3.2.1 Black-Box test………

45

5.3.2.2 White-Box test………

45

5.3.3 Numerical Result………

45

5.3.3.1 Black-Box test………

45

5.3.3.2 White-Box test………

47

5.4

Wear-Leveling………

49

5.4.1 Experimental Setup and Performance Metrics………

49

5.4.2. Test plans………

49

5.4.2.1 Black-Box test………

49

5.4.3 Numerical Result………

50

5.4.3.1 Black-Box test………

50

5.4.3.2 White-Box test………

51

六、

Conclusion

………

54

表 目 錄

表格 1

NAND 快閃記憶體 V.S. NOR 快閃記憶體 ………

6

表格 2

實驗環境設定………

30

表格 3

The experiment result of Normal case………

35

表格 4

The experiment result of Large file case………

36

表格 5

The experiment result of Very Large file case………

37

表格 6

The experiment result of Small file case ………

38

表格 7

Wear-leveling Experiment result (PostMark) ………

51

表格 8

Wear-leveling Experiment result (Sequential write) …………

52

圖 目 錄

圖表 1

Difference between traditional File-System and flash

File-System ………

4

圖表 2

The structure of Flash Memory………

7

圖表 3

三種不同的NAND Flash Memory使用方法 ………

8

圖表 4

利用 RAM 中建立的 Mapping table 處理 Logical Address 和

Physical Address 之間的轉換………

9

圖表 5

FTL address translation………

10

圖表 6

The Example of Garbage Collection………

11

圖表 7

各種 Wear-leveling Algorithm 產生的結果 ………

13

圖表 8

The data structure of JFFS2 stored in flash………

17

圖表 9

The data structure of YAFFS stored in flash ………

18

圖表 10

The data structure of NFTL stored in flash ………

19

圖表 11

The JFFS2 structure when open a file ………

22

圖表 12

The JFFS2 structure of opening directory ………

23

圖表 13

YAFFS 的 address translation (Tndoe-tree) ………

23

圖表 14

NFTL address translation………

24

圖表 15

Garbage collection policy of JFFS2………

27

圖表 16

Garbage collection policy of YAFFS ………

28

圖表 17

Garbage collection policy of NFTL………

29

圖表 18

系統架構圖………

31

圖表 19

Normal case (By count) and Normal case (Use file cumulation)

32

圖表 20

Large file case (By count) and Large file case (Use file

cumulation) ………

33

圖表 21

Very Large file case (by count) and Very Large file case (use

file cumulation) ………

33

圖表 22

Small file case (by count) and Small files case (use file

cumulation) ………

34

圖表 23

Result of Normal case ………

35

圖表 24

Result of Large file case………

36

圖表 25

Result of Very large file case ………

37

圖表 26

Result of Small file case ………

38

圖表 27

Memory consumption of Postmark ………

41

圖表 28

Memory consumption (JFFS2) ………

42

圖表 29

Memory consumption (YAFFS/NFTL) ………

42

圖表 30

Memory consumption - Many Small Files should be written or

read………

43

圖表 31

Garbage collection 的實驗模組………

44

圖表 33

NANDsim device and MTD device layer's time performance in

PostMark (Garbage collection) ………

46

圖表 34

PostMark r/w/e count (Garbage collection) ………

46

圖表 35

Sequential write time performance (Garbage collection) ……

47

圖表 36

NANDsim device and MTD device layer's time performance in

Seq. write (Garbage collection) ………

47

圖表 37

Sequential write r/w/e count (Garbage collection) ………

47

圖表 38

JFFS2 , Interlacing write time performance (Garbage

collection) ………

48

圖表 39

YAFFS and NFTL , Interlacing write time performance

(Garbage collection) ………

48

圖表 40

NANDsim device and MTD device layer's time performance in

Interlacing write (Garbage collection) ………

49

圖表 41

Interlacing write r/w/e count (Garbage collection) ………

49

圖表 42

Erase Distribution after PostMark (JFFS2) ………

51

圖表 43

Erase Distribution after PostMark (YAFFS) ………

51

圖表 44

Erase Distribution after PostMark (NFTL) ………

51

圖表 45

Erase Distribution after Sequential write (JFFS2) ………

52

圖表 46

Erase Distribution after Sequential write (YAFFS) …………

52

圖表 47

Erase Distribution after Sequential write (NFTL) ………

52

圖表 48

Erase Distribution on Static/Dynamic 90/10 space (JFFS2) …

53

圖表 49

Erase Distribution on Static/Dynamic 90/10 space (YAFFS) …

53

圖表 50

Erase Distribution on Static/Dynamic 90/10 space (NFTL) …

53

Benchmarking Embedded Storage System

Shi-Hao Tzeng and Li-Pin Chang Department of Computer Science

National Chiao-Tung University, Hsin-Chu, Taiwan 300, ROC [email protected],[email protected] Abstract 快閃記憶體已經成為嵌入式計算環境的主流儲存媒體。拜嵌入式處理器效能 長足進步之賜，處理大量資料已經不是桌上型電腦或者大型主機的專利了。快閃 記憶體本身有著相當獨特的物理特性，因此以往設計給磁碟的檔案系統並不能直 接使用在快閃記憶體上。也由於這個原因，對以磁碟為基礎所設計的效能評比與 工具，並不能反映一個針對快閃記憶體設計的檔案系統的良莠。因此，本論文著 眼於如何針對以快閃記憶體為基礎的檔案系統做一有系統的評比測試，目的是為 了呈現以往測試評比工具所不能顯現的效能差距。這樣的結果，除了可建議使用 者在某些工作負荷下應該用哪一種檔案系統，更重要的是，避免選擇在該工作負 荷下效能不彰的檔案系統。

Key word: Filesystem Benchmark, embedded storage, flash memory, Garbage collection, Wear-leveling, JFFS2, YAFFS, NFTL

1. Introduction

.

在嵌入式儲存系統(Embedded storage system)中，由於快閃記憶體(快閃記憶體)擁有 低成本,體積小和低耗電量的好處，因此經常被作為嵌入式系統的主要儲存體。目前常 見的 NAND 快閃記憶體有 NAND 和 NOR 兩種技術，特別是 NAND 快閃記憶體有許多 有更利於儲存系統的優點(低價格，高容量)，導致它在嵌入式資料儲存方面上受到重 用。隨著 NAND 快閃記憶體 (NAND 快閃記憶體)的可存容量(Storage capacity)快速的 發展和增加，不久的將來除了在嵌入式系統上的儲存體應用之外，也有很有可能被廣泛 地應用到一般桌面 PC 上。 一般而言在現今桌上型個人電腦和筆記型電腦中，常用的儲存裝置為磁碟為主的儲 存體(磁碟為主 storage)，所以傳統的檔案系統的設計考量大多是因應磁碟特性來設計 的，並不適合直接使用來管理快閃記憶體。主要的差別在於磁碟儲存體的資料更新動作 是採取in-place updates1_{策略。由於快閃記憶體晶片中，是被劃分為許多相同尺寸的區塊} 1

In-place updates：一種file-system處理檔案placement的策略。一般disk file-system中常見的策略。 更新檔案時，file-system會直接將新的檔案data覆蓋到舊有的data儲存的physical位置上。

(Block)，而這些區塊又被切分成許多相同大小的頁(Page)。資料寫入的動作是以一個頁

為單位，被寫過的頁是不能直接再被重新寫入資料的(overwrite)，必須經過抹除(Erase2

) 的動作之後，才能再次寫入資料，而抹除的動作則是以一個區塊為處理單位，所以每次 抹除的動作會消除多個頁中的資料。因此為了避免每次更新都執行抹除的動作，在更新 資料時，通常是再找另一個free page來存放更新的資料(valid data)，並將舊資料標示為 無效(invalid)，這一種資料更新策略稱之為out-place updates。在這兩者不同的策略下， 使得快閃記憶體有許多不同於磁碟的議題要考慮。快閃記憶體中還有另外一個特別限 制，就是每個區塊的抹除次數是有限的。目前的技術下，一個區塊大概可承受 100K次(約 105)的抹除動作，超過次數的區塊可能就無法正常地執行讀寫動作。 由於 out-place updates 的緣故，為了管理快閃記憶體的資料儲存情形，就要額外處 理和紀錄資料邏輯位址和實體位址的變化狀況，所以快閃記憶體檔案系統會建立位址轉 換的機制，來掌握檔案的邏輯位置和快閃儲存體中實體位址對應的關係(logical to physical address translation)。當回收快閃記憶體中使用過的空間時，這些空間需要經過 抹除之後才能再次利用，若要抹除的空間中有存放 valid data 則要將它搬移到其他的可 用空間上存放，這一連串跟回收空間相關的動作稱為垃圾回收(Garbage collection)。由 於每個區塊被抹除的數量有限，為了延長快閃記憶體的壽命，通常會希望快閃記憶體上 的區塊是很平均地被抹除，這概念稱為平均磨損(Wear-leveling)。 由於上述的原因，若將磁碟使用的 inplace-update 方式運作在快閃記憶體上是沒有 效率的，因此目前磁碟檔案系統不適合直接用在快閃記憶體上，而且在磁碟檔案系統中 強調的迴轉延遲(Rotational delay)以及讀寫頭性能最佳化(seek penalty optimization)對快 閃記憶體來說，也是沒有太大功效的，另外在磁碟檔案系統對於平均磨損並沒有作額外 的考量和支援。

由於現有檔案系統的不合適直接用來管理快閃記憶體，因此便有人設計出新的檔案 系統的形式來解決快閃記憶體的檔案 管理問題，主要有下列兩種。1.利用 Flash translation layer，例如 FTL 和 NFTL。好處是讓現在既有的磁碟為主的檔案系統(ext2,FAT 等)可以直接管理快閃記憶體，只需透過一層 Flash translation layer 來處理邏輯位址和實 體位址的轉換關係。2. Native flash 檔案系統，例如 YAFFS 和 JFFS2。好處是針對快閃 記憶體的特性製作的檔案系統，能更有效地利用快閃記憶體上的空間和更快速地處理邏 輯位址和實體位址的轉換。 不論是磁碟為主的檔案系統或是快閃記憶體的檔案系統都可以在各種情形下良好 的運作。而“哪一種檔案系統是我的系統應該使用的？”。這個問題的解答，通常都可以 2

Erase： Flash 中特有的operation，flash是一種write once的儲存裝置，需依靠erase這個動作，來 清除區塊上已寫過的資料，經過erase手續之後的區塊，區塊中的bit會回覆到全部都是 1 的狀態， 並可在此區塊再次執行寫入的動作。

透過檔案系統效能評估(File-system Benchmark)評量結果的好壞來獲得。我們認為好的 效能評估方法除了可以根據使用者的工作需求(workload)和系統的資源限制來評量出適 合的檔案系統之外，更應該進一步告知使用者應該避免使用的檔案系統有哪些。由於現 有的檔案系統評估方式(File-system benchmark)都是用於量測磁碟為主的儲存系統，大 多是針對讀取的回覆時間和磁碟的動作時間來分析效能，並沒有針對快閃記憶體儲存系 統特性(位址轉換，垃圾回收和平均磨損)的評估方法。除了沒有適合快閃記憶體評量結 果的數據之外，也缺乏告知使用者，"哪一種檔案系統適合我們自己的系統？”以及”我 們的系統應該避免使用那一種檔案系統？”等相關資訊。 在這份研究中，我們提出一些嵌入式儲存系統特有的議題，包括上述提到的快閃記 憶體特性位址轉換,垃圾回收以及平均磨損等，對於以上的議題在檔案系統的效能評估 上的影響作深入地探討。我們在之後的章節中會利用兩個主要的實驗方式：黑盒子 (Black-Box)和白盒子(White-Box)。在黑盒子的實驗方法中，我們就是利用常用的檔案 系統效能評估方法(Postmark)或是模擬日常普遍的檔案分佈和運作模式來測量。相反 地，白盒子的測試方式中，除了基本的循序讀寫之外，我們也會透過觀察和了解嵌入式 檔案系統的行為之後，在針對各個快閃記憶體檔案系統的優缺點去設計不同的實驗樣 本。觀察分析的數據，除了評量檔案系統中常見的 CPU 效能,RAM 效能以及反應速度 的快慢和儲存空間的利用度之外，還會分析快閃記憶體特有的數值，如區塊壽命的磨損 快慢程度和垃圾回收的效能好壞等。更進一步，希望能透過實驗的結果，藉此說明在哪 些特殊情形限制下應該避免使用哪一種的嵌入式儲存系統。 本論文的架構組織如下：第二章摘要了一些過去針對檔案系統和 I/O 系統的效能評 估方式與工具作一個概括性的整理。第三章敘述兩種快閃記憶體 NAND 和 NOR 的特性 和快閃記憶體檔案系統主要的議題。第四章主要是敘述每項議題的目的、重要性以及所 要評比的重點為何。第五章為實驗的環境設定、方法以及實驗的結果和討論。第六章為 本論文的結論。

2. Motivation & Related work

由於快閃儲存體被大量的使用於 3C商品上或是工業的應用上，因此如何位 自己的作業系統選擇一個合適的嵌入式儲存系統，也是許多人煩惱的課題之一。 雖然目前檔案系統的效能評估方法有許多種，但普遍都是針對磁碟儲存系統設計 的。雖然也有人使用其中的一些方法來評量快閃記憶體檔案系統的效能，但大多 是止於讀寫的反應時間和掛載時間的測試。但磁碟型儲存體和快閃記憶體的物理 架構不同，也導致這兩大類型種儲存系統的設計走向的不同(如圖表 1)。除了一 些原本的測試項目之外，更應該著重觀察快閃記憶體相關的數值表現，例如：抹 除次數,垃圾回收的效率,空間利用度等。或是更進一步的配合嵌入式系統的需 求，去研究系統耗電量,記憶體使用量,系統穩定度等和嵌入式應用先關的項目。

因此我們便想進行對於嵌入式儲存系統的效能評估，去設計一些需要觀察的項目 和可行的辦法。

圖表 1.Difference between traditional File-System and flash File-System

目前常見的磁碟型檔案系統的評量方法，可以分為下列 3 大類[19]： „ Macro-benchmarks：利用一些特別的工作量去代表一些現實常見的工作量進 行測試，進而表現出各個檔案系統的優點和缺點。 „ Micro-benchmarks：只著重於某一部分的檔案操作指令，去呈現出各個檔案 系統在一些特別觀點的表現。 „ Trace replays：利用程式去重新表現出真實系統所紀錄下來的操作指令，進 而得到更貼近現實的工作量。 依照上述分類的方式我們可以將一些經常被使用的檔案系統評估方式都分成這 3 大種。

首先看到屬於 Macro-benchmarks 的量測方式有 Andrew benchmark [14,20] , Postmark [17], AIM7[21],,和 IOzone [18]。Andrew benchmark 主要是模擬使用者日 常生活會使用的指令建構出一連串的執行步驟，並測量這些動作在待測的檔案系 統運作時的各種數據。 而 PostMark 是模擬使用者日常使用網路的習慣，例如收 發 email,觀看網路新聞和其他瀏覽網頁的行為。PostMark 會在待測的檔案系統中 自行創造出一些類似 cookie 的小型檔案以及一些類似增刪網頁暫存檔的動作來 達到效果，並紀錄過程中檔案讀寫的次數和總量，以及花費的時間，經常被拿來 當作檔案系統的評比工具之一[22,23,24,25]。最後 IOzone 是可以產生和量測許多 種的指令動作，可以觀察各種動作在檔案系統中花費的時間，比較著重於觀察 I/O

的效能表現[25]。AIM7 會產生許多平行執行的程序，每一個程序都執行一些動 作和隨機的呼叫內建的工作內容，包含一下系統指令(磁碟讀/寫)動作，pipe I/O， 以及一些消磨 cpu 時間的迴圈工作)。之後計算出每分鐘完成的工作個數，在[25] 中被使用為評比工具之一。

其他的 Macro-Benchmark 的測量工具還有 Netbench[29]和 Dbench [30]。 NetBench 是一種量測檔案伺服器的評比工具，主要利用多台 PCs 之間的網路連 接，來模擬使用者向伺服器請求檔案的 I/O 的要求。Dbench 是一個作用於 LINUX 上的 open-source 程式，和 NetBench 相同是評測檔案伺服器的工具，Dbench 所 產生的工作量就像是 NetBench 作用於不需要發出網路請求的 Samba server 上一 樣。這兩個評比檔案伺服的工具在[35]中被使用到。

Micro-benchmarks 中較具代表性的量測方式就是 Bonnie and Bonnie++[16]， 主要是測試 I/O 輸出的產能，會製造一些 page cache 無法完全吸收的大檔案來量 測檔案系統在 I/O 表現上的極限，盡可能快速地去讀寫這些大檔案。其他的 Micro-benchmark 方法還有 Sprite LFS[31]，Sprite LFS 的測試方式有兩種 Sprite LFS Large File Benchmark 和 Sprite LFS Small File Benchmark。Sprite LFS Large File Benchmark 被使用於[32,33,34]作為測試效能的工具，主要的步驟示對於容量 為 100MB 的大檔案作循序和隨機的讀寫運算(讀取和寫入的資料量大小都是 100MB)。Sprite LFS Small File Benchmark 在[32,33,34]被使用到，主要的實驗步 驟是先建立 10000 個以上 1KB 的檔案，再利用 flush 寫回 page cache 中暫存的資 料後，再進行讀取全部檔案的動作，最後再刪除所有檔案。 Trace replays 這一類型的測量方法，主要都是使用者自行撰寫模擬程式去分 析和重現，他們自己收集到的紀錄檔(trace log)，而這些程式也都會依照使用者 自己的需求和各自紀錄的紀錄檔不同而有不同的部份。如[13]中作者利用自行撰 寫的程式分析收集的 trace log。 Iometer[26]不屬於上述 3 種類型的量測工具，可以透過使用者設定而模擬任 意的磁碟和網路 I/O 動作，所以 Iometer 既可以當作工作量產生器(workload generator)來使用，也可以當成一種量測的工具。在[25]中被作者自訂成自己的量 測工具 pmeter。 但上面提到的檔案系統測量方法大多數主要還是用於測量磁碟為主的檔案 系統，而非針對快閃記憶體去量身打造的。在嵌入式儲存系統上，評測工具非常 少見。[8,9]中作者提出量測評量嵌入式系統中處理器和快閃記憶體裝置的個別的 耗電量，利用一個 macro-model 來量測 CRAMF,RamFS,JFFS2 的耗電量，且不需 要任何實際量測電力的工具[8,9]。 接下來我們會先介紹快閃記憶體檔案系統和磁碟檔案系統不同的幾個主要

的議題，並探討在之後的量測方法中應該注重的部份為何，以及為什麼要量測這 些數據。

3. Fundamental Management Issues of Flash-Memory Storage

Systems

在這個章節，我們在 3.1 首先介紹快閃記憶體的物理架構，然後在 3.2 介 紹目前快閃記憶體在儲存系統中所佔的層次為何，接著 3.3 至 3.5 則介紹快閃記 憶體 3 個主要管理議題：位址轉換，垃圾回收和平均磨損。

3.1 Flash-Memory Physical Geometry

由於快閃記憶體有非揮發性(non-volatile)，抗震(shock-resistant)，和 省電 (power-economic)優點，是被經常用於充當嵌入式系統(embedded system)中的儲 存體。目前市場上主要有兩種不同的快閃記憶體: NAND 和 NOR 快閃記憶體。 這一章節中主要著重在介紹 NAND 快閃記憶體的概觀和硬體特性。 NAND快閃記憶體主要就是設計作為儲存資料之用，而NOR 快閃記憶體主 要用來取代EEPROM的。由於NOR是採取標準的記憶體介面,所以CPU處理器可 以直接執行儲存再NOR上的程式(亦可稱為eXecute-In-Place, XIP)。表格 1.為比較 NAND快閃記憶體和NOR快閃記憶體主要的差異[3]。因為NAND快閃記憶體更適 合作為主要的儲存系統，所以之後的討論我們會將焦點集中放在NAND快閃記憶 體的議題上。 表格 1. NAND 快閃記憶體 V.S. NOR 快閃記憶體 NAND NOR

Density High Low

Read/write Page-oriented Bitwise

eXecute In Place (XIP) No Yes

Read/write/erase Moderate/fast/fast Very fast/slow/very slow

Cost per bit Low High

NAND 快閃記憶體由於便宜，體積小，耗電量小，以及其可媲美硬碟容量 的儲存空間，因此被廣泛地應用在各式常見的 3C 商品上作為主要的儲存空間。 因此用於管理 NAND 快閃記憶體上空間應用的檔案系統也開始顯得格外重要。 但因為 NAND 快閃記憶體擁有許多不同於一般磁碟的性質，使得目前桌面型電 腦上所使用的檔案系統不適合在快閃記憶體上運作。而快閃記憶體共通的特別之

處在於 1.一次寫入(Write-Once)，2.大量抹除(Bulk erase)，3.有限的抹除次數(limit erase cycles)。

圖表 2. The structure of Flash Memory

首先介紹快閃記憶體的基本架構，如圖表 2所顯示。每一個快閃記憶體晶片 主要是由許多同等大小的區塊所組成，而每一個區塊又是由許多個相同大小的頁 所構成。每個頁又分為兩個區域分別是使用者區域(user area,通常為 512bytes)和 備用區域(spare area,通常為 16Bytes)，其中使用者區域用來是擺放使用者儲存的

一般資料的地方，而備用空間是留給檔案系統擺放管理系統所需的Metadata3_所

使用的。一般快閃記憶體中執行抹除動作的單位為區塊，而讀/寫動作則是以頁 為單位。在快閃記憶體中，我們通常將存有最新資料的頁稱為live page(或 clean page)，反之儲存舊資料的頁則稱為dead page(或dirty page)。一般的情形下，同一 份資料在快閃記憶體中應該會有許多份的dead page和一份最新的live page，而這 一份擁有valid data的live page位址會因為更新的狀況不斷的改變，不一定會固定 儲存在快閃記憶體的固定的位置。

3.2 Flash Memory in Storage Hierarchy

一般使用快閃記憶體作為非揮發性的儲存媒介(non-volatile storage media)的 方法有 3 種，如圖表 3 所示。1. Host driver emulate: Smart MediaTM

(SM)[5],

MemoryStickTM(MS)，由於內部不含控制晶片，必須搭配特定的控制器(driver

controller)才能運作，泛用性和系統支援性較低。(如圖 3.a)2. Standalone block device:在NAND快閃儲存裝置的本身內部就包含了控制晶片，例如

CompactFlashTM(CF)卡[6], Secure Digital Memory Card (SD)卡,USB thumb drives 和 M-system Disk On Module(DOC) (如圖 3.b)[7]。3. Native Flash file system：

3

JFFS1, JFFS2/JFFS3, YAFFS1/YAFFS2, MFFS[10,12,15]等，特別為NAND快閃記 憶體量身訂做的檔案系統。其中Native flash file system的各種特性便是這篇研究 要探討的重點所在。(如圖 3.c)

Native file system 抓取檔案是實體位址的方式，是利用檔案名稱(file ID) 和 偏移量(offset)，再透過檔案系統的資料結構轉換得知實體資料在快閃記憶體上的 實體位址(physical address)。而 block device emulation 則由原本所使用之磁碟檔案 系統(Disk-based file system)獲知檔案名稱和偏移量，得到儲存資料所在區段數 (sector number)後，再把這個區段數經由 NFTL 和 FTL 等的 block device emulation 轉換和對應下得知資料在快閃儲存體上得實體位址。

圖表 3. 三種不同的 NAND Flash Memory 使用方法 (a) Host driver emulate，(b) Standalone block device，(c) Native Flash file system

3.3 Address translation

為什麼在快閃記憶體檔案系統中需要另外再做一層邏輯位址到實體位址的 轉換呢？原因有二：1.不想每次寫入之前，都必須做抹除。2.Hot Data 都有區域 性(locality)。若重複讀寫在同一塊區塊中，會快速耗損快閃記憶體壽命。兩個原 因主要都是受限於 NAND 快閃記憶體的物理行為。 原 因 一 ， 是 由 於 在 NAND 快 閃 記 憶 體 特 殊 的 物 理 性 質 ( 參 考 3.1 Flash-Memory Physical Geometry)，導致快閃記憶體再更新資料時不能採取一般 磁碟的常見處理方式(In-place)。假若要仿造磁碟為主的檔案系統(disk-based filesystem)處理資料擺放的方式(data placement)，則必須在執行更新資料的寫入

動作之前先將已寫過的 dirty 區塊作抹除動作，而處理抹除的時間比一般讀/寫 (unit: page)時間還要長，並且在動作期間 NAND 快閃記憶體 device 無法並行執 行其他動作，倘若每次要對 NAND-快閃記憶體作資料寫入的動作時，都需要先 強迫浪費一段時間要處理抹除動作，迫使執行跟更新(Update)有關的寫入動作時 就需要花費大量時間(erase time+ write time)，因此會導致檔案系統的產能 (throughput)降低，而拖慢檔案系統整體的運作速度。

原因二，主要是由於資料的從讀寫的頻率上來看是有Hot data與Cold data之

分4_{的，然而在一般的磁碟為主檔案系統中Hot data都具有相當高的區域性} (locality)。經常性更改的資料通常都會群聚在一起，作用在快閃記憶體之上之 後，由於這些資料經常性的更動，會不停的將資料更新到快閃記憶體上。因此隨 著資料經常性的更新，便必須不斷地對儲存過這些hot data的區塊執行抹除回收 再複寫新資料的動作，長久下來會導致這幾塊區塊的壽命快速的被耗損，最後成 為無法使用的bad block。然後不斷重複相同的動作，使得NAND快閃記憶體中的 可用空間不斷減少，惡性循環之下也加快耗損整個快閃記憶體的壽命。 由於以上兩種 NAND 快閃記憶體的運作缺點，使得快閃記憶體檔案系統在 資料的更新寫入時，為了避免抹除動作產生的時間和額外的負擔，所以在資料的 更新上是採取不同於 in-place updates 的策略。快閃記憶體為主的檔案系統在處理 檔案的更新時，是直接將寫入資料放置在與原本不同的頁面中，來避免每次更動 資料就必須抹除的動作。以上這種將資料寫入非原始的資料位址的方法，稱之為 “Out-place”。但這個時候就必須要作位址轉換的處理，否則 read/write 相同檔案 時會發生錯誤(由於檔案在快閃記憶體上的實體位址已改變)。因此快閃記憶體 檔案系統通常必須在 RAM 中額外建立一層位址轉換的機制來處理在使用者眼中 檔案的邏輯位址(Logical address)和檔案實際對應到快閃記憶體上的實體位址 (Physical address)之間的映成關係(圖表 4.)，避免檔案 read/write 時會發生錯誤。

圖表 4. 利用 RAM 中建立的 Mapping table 處理 Logical Address 和 Physical Address 之間的轉換

所以為了要方便去處理和實作Out-place，快閃記憶體檔案系統是利用上述作

4

Hot Data/ Clod Data：對儲存於storage中的data，利用讀取的頻率的高低不同所作出的區分。Hot data 是指經常被系統update或是user 更改的data，一種經常不斷的在更動的data，反之稱為Cold data。

一層位址轉換(address translation)的方式。利用各自定義的資料結構儲存額外的 資訊(Metadata)，進而利用這些Metadata在主記憶體中建造處理位址轉換的對應 表 。 例 如 ： Flash Translation Layer (FTL) 便 是 利 用 一 個 位 址 轉 換 表 (address translation)來進行logical block address(LBA) 和 physical block address(PBA)的轉 換(如 圖表 5 FTL address translation )。先是在主記憶體的位址轉換表中讀取 LBA(3)的數值發現是對應到PBA(0,5)，即第 0 個區塊中的第 5 個頁面，因此可知 在LBA(3)的這個頁面中的資料，是在實體快閃記憶體上第 0 個區塊中的第 5 個 page上作讀取或寫入。然而各個快閃記憶體 檔案系統都有必須要有各自處理位 址轉換的資料結構和位址轉換表的機制，會是快閃記憶體檔案系統的主要核心課 題之一。 圖表 5. FTL address translation 然而，位址轉換雖然解決了實作Out-place的主要問題，但也引發了不少值得 深入探討的議題。首先由圖表 5中FTL可看出每一個主記憶體中的頁面也是對應 到快閃記憶體中的一個頁面，表示即使當使用者只是對檔案作了一點點的更改， 依然是要快閃記憶體重新寫入一個頁面，但可能是整個頁面資料更變小部份後再 寫入，或是只寫入那更動的資料(其他剩餘空間則填空浪費)，所以在這邊可以知 道位址轉換的對應階層(mapping level)(NFTL和YAFFS為page-Level，JFFS2 為 node-Level較特別)會影響到快閃記憶體 檔案系統處理微小更動產生的read/write 和回覆時間(response time)。

3.4 Garbage Collection (GC)

由於快閃記憶體 write-once 的特性和快閃記憶體 檔案系統中採用 Out-place 的方式，而 invalid (dirty) 區塊必須藉由抹除動作來還原成可用的空間，其中由 於抹除的單位和 read/write 單位不同，會導致需要抹除的區塊中會有 valid(clean) page 的存在，必須將這些頁面中有用的頁面保存搬移到其他的區塊上之後，再

進 行 抹 除 區 塊 的 動 作 ， 而 這 一 連 串 步 驟 和 觀 念， 稱 之 為 垃 圾 回 收 (Garbage collection。)

圖表 6. The Example of Garbage Collection

垃圾回收在一般快閃記憶體檔案系統上的處理動作，大致上的步驟如圖表 6 的範例表示的。首先要被抹除的Erased block上的含有有效資料(valid data)的頁面 (page)一個個都拷貝到其他可用頁面(free pages)上(圖表 6中的(1))。再將被拷貝 過的頁面通通標記成無效頁面(dirty page)(圖表 6的(2))，最後對這個全是無效頁 面(dirty page)的區塊進行抹除，完成回收這個區塊空間 (圖表 6的(3))。從圖 6. 的範例可看出，這個垃圾回收動作實際所回收的可用空間是 4 個頁面，所以回收 的效益是 50%(抹除一個包含 8 個頁面的區塊，但實際只多得到 4 個可用頁面的 空間)。 其中整個垃圾回收動作中最主要的額外負擔(overhead)，就是上述範例中的 拷貝的動作，可看出垃圾回收的動作花費的時間長短和需要被拷貝的頁面數目或 有效資料(valid data)量有關，當上述步驟裡要被抹除的區塊中需要被搬移的頁面 數越少，表示垃圾回收中額外花費在執行拷貝的時間相對的越少，那麼整體垃圾 回收的動作越快。因此選擇一個”較適當的區塊”來執行垃圾回收(期望拷貝次數 低，回收空間大)，可以大大降低花費在垃圾回收的時間和提高垃圾回收的效益。

由於檔案系統中的資料種類一般區分為Hot data和 Cold data4_{。其中hot data}

較多，則會發生區塊抹除過後，被拷貝的頁面馬上又變成dirty page的情形，也會 導致剛剛所作的拷貝動作是無意義的和多餘的，而且也可能馬上又造成回收區塊 的可用空間又耗盡，馬上又需要再作一次垃圾回收。如此惡性循環下，會導致系 統花費許多時間不停地在作垃圾回收，而不是去處理使用者存取請求(r/w request)。最後造成系統不斷地由於垃圾回收去抹除區塊，除了系統效能低落之 外，也會使得NAND快閃記憶體壽命快速地消耗殆盡。 因此如何做到垃圾回收執行時，做好hot/cold data的區分，盡量避免垃圾回 收去拷貝到hot data之page，來這種減少無意義的拷貝發生，也是垃圾回收演算法 中一個相當重要的考量和議題[11]。由於現今的快閃記憶體檔案系統中的垃圾回 收動作，大部分是採取貪婪策略(Greedy policy)5_{的作法，雖然回收空間的效益是} 最高的，但卻沒有考量到挑選出的區塊中所要搬移的頁面是否被hot data所盤 據。雖然在短期內從效益看起來是最佳的作法，但長期下來就極有可能會發生我 們上述的最壞情形。當不斷地挑選到Hot data為多數的區塊來抹除，並持續地惡 性循環下，系統只能不斷地執行垃圾回收動作，無暇處理使用者的命令。之後的 章節也會考量這些情況的發生，並分析各個快閃記憶體檔案系統的應對能力如 何。

3.5 Wear-Leveling

由於快閃記憶體中每一個區塊都有抹除的次數限制。若某個區塊的抹除的次 數超過限制，則此區塊則會標示成 bad block，表示這個區塊已損壞且不能再使 用了。過多的 bad block 會導致快閃記憶體檔案系統運作困難，甚至也可能無法 再正常運行，表示那塊快閃記憶體無法再使用。因此如何去平衡各個區塊的抹除 次數，達到充分的利用到整個快閃記憶體空間的方法和觀念，稱之為平均抹除 (Wear-leveling)。

由於快閃記憶體的區塊都有有限的 erase cycles 限制。一般而言，一個 NAND 快閃記憶體的區塊的 erase cycle 約在 100K 次左右[2]，表示當區塊被抹除超過 100K 次之後便可能會不能再被抹除，導致區塊無法再被垃圾回收回收使用，形 成 bad block。而當一個快閃記憶體中 bad block 越多，會導致檔案系統中可用的 區塊越少，因此可供分擔因 Hot Data 流竄造成的負擔的區塊越少，更加速了剩 餘區塊被抹除的速度，最後當 bad block 的數量到達一定的程度之後，會使得檔 案系統無法再正常運作下去，即使系統中顯示有不少可用空間。在快閃記憶體 檔 案系統中經常是造成 dirty page 的主要原因。然而，一般而言快閃記憶體檔案系 統的垃圾回收策略都是採取貪婪(Greedy)，表示 dirty page 越多的區塊通常較受 到這垃圾回收策略的喜愛(可回收的空間大，且拷貝搬移的次數少，花費的時間

5

短，垃圾回收所得的效益高)，反之擁有許多 Cold data 的區塊通常不會受到這類 垃圾回收策略的青睞(可回收的空間小，需拷貝搬移的次數多，花費時間長，垃 圾回收所得效益低)。乍看之下，使用貪婪(greedy)法則的垃圾回收似乎能得到最 大效益(花費時間短，回收空間大)。

但若將檔案系統中常見的 hot/cold data 分佈的情形考慮進去的話[3]，一般情 形之下，是由 Cold data 佔據整個檔案系統的大部分的空間，hot data 只佔整體 data 量的少部份。由於 Cold data 極少更動，導致垃圾回收在挑選犧牲者區塊時，會 經常去挑選到由於 Hot data 變更所製造出來的區塊(因為包含 dirty page 的成份通 常較高，回收空間的效益較好)，最後可能導致 Hot Data 只在一小部份的區塊中 流竄，使得這些區塊的抹除次數不斷增加，相對的其他被 Cold data 佔據的區塊 則鮮少被抹除(垃圾回收不喜愛挑選這類的區快來回收，需要拷貝搬移的頁面數 量太多)，造成快閃記憶體中整體區塊的各區塊的抹除次數極不平均。最後不斷 地惡化下去，迫使這些區塊不斷執行垃圾回收動作，導致他們的壽命(erase cycle) 快速地被消耗殆盡，最終成為不能使用的 Bad Blocks。由於這些 bad block 已無 法再利用，所以原本在這些 bad block 中流竄的 Hot data，只好移動到剩餘可供 read/write/erase 的區塊上，開始另一次類似上述動作的循環。如此下去也就加快 flash 中其他區塊的使用壽命，直到整塊 NAND 快閃記憶體不能再被使用為止[4]。 圖表 7 中所表示的就是使用平均磨損演算法後常見的 3 種結果圖表 7(a), 圖 表 7 (b)和圖表 7 (c)分別是代表沒有使用任何的平均磨損演算法,使用額外負擔 (overhead)6高的平均磨損演算法,以及使用良好的平均磨損演算法的 3 種現象。當 然由圖表 7 (b)上可以得知不好的平均磨損演算法，雖然能使達到區塊平均磨損， 但額外付出的代價卻相當的高。例如圖表 7 (b)中表示的，使用演算法後整體區 塊的抹除次數全都一起提高，額外的抹除動作多出許多，反而消耗更多的抹除次 數(erase cycle count)。所以在額外負擔很大的影響之下，利用來延長快閃記憶體 壽命的平均磨損演算法，反而加速耗損快閃記憶體的使用壽命，最後的結果會比 沒有使用平均磨損演算法的圖表 7 (a)更糟糕。由此可以平均磨損最大的目標是” 利用盡可能少的額外負擔(overhead)，去達到flash中所有區塊的磨損平衡。”

圖表 7. 各種 Wear-leveling Algorithm 產生的結果(a)未使用 wear leveling 或者 wear leveling 無

6

Overhead:在垃圾回收中，主要的額外負擔是為了搬移有用資料所花費頁面拷貝的次數。而在平 均抹除中，主要的額外負擔是用來平均各區快抹除次數所執行額外的讀/寫/抹除產生的，其中最 看重的是抹除次數。

效，(b) wear leveling 帶進過多的成本，(c)期望之 wear leveling 效果。

4. Flash-Memory-Based File-System Benchmarks

在之後的部份，我們會討論我們所觀察到的 3 個主要的快閃記憶體檔案系統 (JFFS2,YAFFS 和 FAT32+NFTL)運作概念，並逐一解說他在各個主要議題的實作 方式，以及獨特的地方。我們會先針對幾個評量的主題作個說明和解釋實驗的精 神和目的，除了主要的概念之外，也會分析各檔案系統的設計優缺點和之後觀察 評量的要點項目(如：時間，抹除次數，記憶體使用量等)，之後會再利用這些項 目去設計實驗的著重部份。

4.1 Flash-Space Utilization

這邊要先深入探討的是空間使用率(space utilization)，這一部份討論的重點 在於 Flash 的空間是否有被檔案系統充分的利用。換言之，也就是看各種快閃記 憶體檔案系統利用空間的效益如何，消費者(使用者)關係的問題也不外乎為”同 樣的 NAND 快閃記憶體可用空間之下，誰能儲存的使用者資料量最多？”，還有” 儲存相同的檔案資料，哪個檔案系統最節省使用空間?” 以及”為什麼明明還有可 用空間，但卻無法再寫入任何的資料？” 上述 3 個問題，主要都和快閃憶體檔案 系統設計用來儲存在 NAND 快閃記憶體上的資料結構有絕大部分關係，另外快 閃記憶體檔案系統在處理位址轉換時的對映階層關系也對空間使用率有很大的 影響。

4.1.1 Performance issues

本章節討論會對 flash-space utilization 效能上造成差距的因素。基於這些因 素，我們後續章節會提出對應的效能評比測試方法。

4.1.1.1 User data & Metadata of File system

首先我們要先了解到有哪些東西是快閃記憶體檔案系統必須要儲存在 flash 上。第一種不用考慮一定是使用者資料，使用者資料也就是使用者主要想儲存於 NAND 快閃記憶體上的資料，也是使用儲存裝置的主因。另外就是快閃記憶體 型檔案系統儲存用來紀錄和管理整個檔案系統的運作時所需的 metadata。這些儲 存於 NAND 快閃記憶體上的 metadata 除了用來紀錄使用者眼中檔案的邏輯位址 (logical address)和實際儲存在 NAND 快閃記憶體中的實體位址(physical address) 兩者之間的對映關係之外，還能用來協助快閃記憶體裝置在開機(boot)階段和檔

案系統掛載(mount)與卸載(umount)的過程中位址轉換對應表(address translation mapping table)的建立以及主要位址對應(address mapping)的方式。因此除了需要 紀錄的資料不少之外，再加上快閃記憶體 write-once 的限制和更新方式使用 out-place 的策略，讓快閃記憶體形成一種特別的特例：”每一份使用者資料都需 要夾帶著一份metadata來紀錄新舊。”因為無法使用磁碟為主的檔案系統，對於 同一份檔案只使用一份 metadata 來紀錄，所以每變更一次檔案便要再多一份新 的 metadata 來辨別新舊，使得快閃記憶體檔案系統的整體使用的 metadata 比一 般傳統檔案系統來的多。雖然已經提供了備用空間(Spare area)供檔案系統來儲存 metadata，但還是有快閃記憶體檔案系統會使用到使用者空間(User space)來存放 metadata(ex: JFFS2)。 在檔案系統建立初期，或是裝置區塊(device block)被以這些檔案系統格式掛 載時，需要讀取整塊快閃記憶體中 metadata 的資料，以便能利用這些資訊來建 立檔案系統的目錄結構和檔案之間整體的樹狀架構，並還能進一步的在主記憶體 中建立檔案和 NAND 快閃記憶體上實體位址之間的映成關係。因此檔案系統中 所使用的 metadata 設計上的優劣，和檔案系統建構步驟的快慢，還有佔用的系 統資源，例如記憶體和 NAND 快閃記憶體空間，以及檔案系統運作時處理程序 的反應快慢有密不可分的關係。基於每個快閃記憶體型檔案系統設計的原理不 同，所擁有的 metadata 量大小也就不同。一般而言，在檔案系統最理想的情形， 是只利用少許的 metadata，不佔用太多使用者空間，還能快速有效的管理系統和 正確處理檔案命令。在之後的實驗中，我們也會去探討這三種檔案系統使用的 metadata 和使用者資料之間比重關係，以及各種變數相同的條件之下各檔案系統 儲存資料量和剩餘空間的比率關係。

4.1.1.2 Fragment

什麼是 Fragment? Fragment 是儲存空間中的零碎無用的部份。在 NAND 快 閃記憶體上形成的原因有幾種情形，可能是剩餘空間太小而不能使用導致被捨棄 的空間，或者是為了達到資料的末端的 word alignment 效果強行填入的少量且無 用的資料，亦或是由於寫入的資料量小於一個頁面大小所浪費的空間。然而由於 fragment 既不是儲存使用者資料，也不是儲存檔案系統的 metadata，所以一個檔 案系統運行時產生的 fragment 所佔的空間越多，則表示檔案系統對於儲存空間 的利用度越差，長期下來也是一種增加快閃記憶體磨損程度的原因之一，所以之 後我們的實驗過程中，也會紀錄分析這 3 種檔案系統中 fragment 產生的多寡。

4.1.1.3 Mapping size effect

快閃記憶體上得資料結構和讀/寫的使用的對應大小(Mapping size)差異下，是否 會有其他更深層的影響。首先在快閃記憶體上影響 Fragment 的大小程度主要原 因就是檔案系統使用 Mapping size。由於這三種檔案系統(JFFS2,YAFFS,NFTL) 所使用的對應大小不一，因此他們所產生的 fragment 大小也各不相同。例如 YAFFS 和 NFTL 是使用 Page-level 的寫入，因此若是要寫入快閃記憶體的檔案資 料量相當小(小於一個頁面的話)，那麼這兩個檔案系統所採取的策略便是將剩餘 非資料的空間用”0”填入，利用”0”補滿一個頁的大小之後再進行寫入，所以在快 閃記憶體中這個頁中除了開頭的部份是使用者資料之外，其餘部份都是檔案系統 填入的垃圾資料，是沒用且無意義的。 相對的，在 JFFS2 中，一份使用者資料的儲存可能是分成多個 Raw node 存 放在 NAND 快閃記憶體上的，而在每一個頁面中擺放的資料可能是包含多個 node 的資料。導致雖然 JFFS2 每次寫入的單位也是頁，但實際寫入的資料大小 可以細分到 node-level。所以在處理許多小檔案的時候，JFFS2 可以將這些不滿 一個頁的小檔案形成的 node 一個一個的集結起來，再一起寫入到一個頁面中， 因此對於空間的使用上相對的會比 YAFFS 和 NFTL 來的節省。但 JFFS2 並沒有 充分利用到快閃記憶體中的備用空間(Spare space)，而是將管理系統。JFFS2 也 是有 fragment 的問題，JFFS2 產生的 fragment 就大多是在每一個頁末端剩餘空間 不足以再寫入下一個 node 的時候，也是採取利用”0”來填滿空缺所產生的 fragment，但這樣的浪費比起另外兩種檔案系統卻顯得微不足道。簡單的說，對 YAFFS 和 NFTL 而言，當使用的快閃記憶體晶片的 page size 越大，就可能會產 生越大的 fragment。

但是，是否檔案系統使用對應大小(mapping-size)越小所得到的效果就越好 呢？這答案當然是否定的，檔案系統所使用的對應大小越小(mapping-size)，檔案 被切分得越細碎，管理上也就越困難，需要紀錄的 metadata 也就越多。以 JFFS2 為例，當一個檔案的各部位被細分成 node，又放置到不同的頁或區塊時，因為 out-place 的 關 係 每 一 個 node 都 需 要 帶 一 份 metadata ， 再 加 上 對 應 大 小 (mapping-size)的微小(node-level)所需要額外紀錄用於管理檔案系統的 metadata 也就多一點，結算下來所用的 metadata 就會比其他檔案系統更多一些。而 JFFS2 為了實現 node-level，使得每一個形成的 fragment size 較小，但也捨棄了使用備 用空間(spare area)，而將 metadata 存放在使用者空間，卻也減少了使用者可用的 快閃記憶體空間。因此在對應大小(mapping-size)的大小之上的取捨是各有優缺 點，沒有絕對的好壞之分。總結，對應大小(mapping-size)越大的使用的 metadata 量越少，相反對應大小(mapping-size)小的使用的 metadata 量較多。

了解過檔案系統在儲存體上會存放的各種形式之後，接下來我們會一一介紹 JFFS2,YAFFS 以及 NFTL 三種檔案系統在 NAND 快閃記憶體上各會使用哪些資 料結構來管理使用者資料和檔案系統本身的 metadata。

4.1.2.1 JFFS2

JFFS2 儲 存 在 快 閃 記 憶 體 上 的 內 容 物 只 有 兩 種 基 本 的 nodes 分 別 為 JFFS2_raw_inode 和 JFFS2_raw_dirent 。其中 JFFS2_raw_inode 主要是用於存放 使用者 資料，而 JFFS2_raw_dirent 則是存放 file name 和檔案的目錄關係的 metadata。不論是 JFFS2_raw_inode 或是 JFFS2_raw_dirent，每一個 node 的資料 量不會大於 NAND 快閃記憶體的頁面大小 (JFFS2_raw_inode 最大的尺寸是 512bytes 等同於一個頁面的大小)。由於使用這兩種基本的資料結構來管理使用 者資料，而每一個 node 大小隨著後面伴隨的資料量不同或是 file name 長度不同 所產生出來的 node 尺寸也就不相同，因此存放在一個區塊中的 node 數量也就 不固定。因為儲存的 node 數量不固定，無法利用統一的格式去管理這些 node 資 訊，所以 JFFS2 放棄使用快閃記憶體中的備用空間(spare area)，將所有的 metadata 和使用者 資料全都集中存放在 使用者空間中。JFFS2 各種資料結構的關係範 例，就如圖表 8.所表示的。圖中只表示出區塊中最後一個頁面中的內容(除了區 塊中第一個頁面外，並非所有 page 都會剛好對齊某一個 node 的起始位置，只是 舉例說明)，由圖可知在 JFFS2 當中，儲存在快閃記憶體上的內容物不外乎為上 述的 JFFS2_raw_inode 和 JFFS2_raw_dirent 兩種 node 結構，以及跟隨在 node 之 後的使用者資料和檔案名稱(file name)。在圖中可看到當 JFFS2 在區塊最後的頁 面中，剩餘空間無法再填入任何的 node 時，會標示成無用的 fragment 空間。

4.1.2.2 YAFFS

在YAFFS中存放資料的基本單位為chunk(對應到記憶體中的一個頁面大 小)，每一個yaffs_Object可能會由許多chunk構成，個數依照檔案的資料量大小 來決定。而每一個yaffs_Object都會有一個yaffs_ObjectHeader， yaffs_ObjectHeader是YAFFS主要的On-Flash 資料結構。yaffs_ObjectHeader存在 於快閃記憶體上，當快閃記憶體掛載上YAFFS時，會為每個yaffs_Object找尋該 物件的yaffs_ObjectHeader，讀出yaffs_Object的相關資訊。yaffs_ObjectHeader 所儲存的資訊如圖表 9所顯示的。快閃記憶體中並非每個頁(chunk)都是存放 yaffs_ObjectHeader，還有其他存放使用者資料的chunk。主要是依靠備用空間 (spare area)中存放的資訊chunkID來辨別這個chunk是否為yaffs_ObjectHeader。 若chunkID=0 則此chunk為yaffs_ObjectHeader，反之則為存放資料的資料 chunk。所以除了chunk0 之外的使用者空間(User area)都是用來擺放使用者資 料。其餘關於YAFFS 資料結構詳細的資訊請參考[10]。

圖表 9. The data structure of YAFFS stored in flash.

4.1.2.3 NFTL

NFTL中使用者區域的部份大都是用來儲存使用者 資料，但根據使用的檔案 系統(ext2/FAT)不同，所會佔用的使用者區域的空間也就不相同。例如NFTL上的 檔案系統若是採用FAT，則當然必須對應建造一個FAT table來管理檔案系統的運 作。NFTL在Flash上的資料結構主要則是存在備用空間(Spare Area)的oobinfo (如 圖表 10. 所示)。OOB則是由bci (block control information)及uci(uni control information)組成，bci記錄每一個頁面的使用狀態status，uci則記錄每一個區塊相

關的資訊。其餘詳細bci和uci紀錄的metadata內容請參考[7]。

圖表 10. The data structure of NFTL stored in flash.

在之後的實驗的部份 Chapter 5，我們會就分為兩種測試方式黑盒子和白盒 子來設計實驗。黑盒子的設計是採用一般使用者在檔案系統中常見的檔案分佈。 黑盒子測試主要是用來測試這三種快閃記憶體檔案系統在一般使用者常見的檔 案分佈下，在看間利用度上表現的情形會是如何？白盒子測試分別是 Large file case(檔案大小約介於 512Kbytes-2Mbytes 之間 ，類似照片等圖檔或是較小的 mp3 檔案,WMA 檔案等等) 和 Very large file case(檔案大小介於 4Mbytes-16Mbytes 之 間 ，類似是完整的 mp3 檔或是影片檔)，以及 Small File case(檔案大小大多小於 一個頁的大小,約 512bytes,模擬當細小的檔案如網際網路暫存的 cookie,系統檔案 和 linux source tree 等，系統中眾多細小檔案時的情形)。

NOR Flash Memory

在 NOR 快閃記憶體上，由於 NOR 可以作 byte-level

的 update 和寫入，因此在 fragment 上的問題便減少了許多，不過由於 NOR 的價 錢昂貴，所以使用空間也就到了錙銖必較的地步。即使產生 fragment 的原因較 少，但是 NOR 快閃記憶體的大小普遍都不大，其可用空間也就格外珍貴。在這 3 種檔案系統中只有 JFFS2 能支援到 NOR 快閃記憶體，而 JFFS2 運行時便會有 word alignment 的情形發生，可能會造成片段的 fragment。但我們研究的重點著 重在 NAND 快閃記憶體，所以在 NOR 這部份便不深入探討了。

4.2 RAM-Space Requirements

這一個章節我們要探討的便是在這眾多的檔案系統中，我們要探討的是三種 檔案系統在一般的工作量(workload)下和一些特殊的情況下，為了維持系統運作 所要佔用的記憶體空間的多寡。 由於在使用快閃記憶體為主要儲存體的嵌入式系統中，大部分的嵌入式系統 只用於某些特定用途，通常系統整體的大小不大，加上為了節省成本和降低電力 消耗量(power consumption)，導致嵌入式系統使用的資源相當有限(低頻率的

CPU，少許的記憶體)。一般的情形下，嵌入式系統所擁有的記憶體，不管是 ROM 記憶體或是 RAM 記憶體都局限在 64MB 以下，所以在資源有限的情形下，一個 設計良好的嵌入式儲存系統運作時是不應該佔據太多 RAM。優良的快閃記憶體 檔案系統應該盡可能節省維持運作所佔用的 RAM 量，並將絕大部分資源都給使 用者進程(process)去運用。

4.2.1 Performance issues

本章節針對為一個快閃記憶體檔案系統所需要的各種 RAM-resident 資料 結構作一討論。這些需求往往與快閃記憶體的物理特性有關，因此與以往之磁碟 檔案系統之需求大不相同。基於這些影響 RAM 空間使用量的因素，我們後續章 節會接著討論如何對這些因素做效能評比。

4.2.1.1 Address Translation

由之前章節 3 所提及的觀念位址轉換可知，快閃記憶體檔案系統為了實現位 址轉換都會利用一些儲存在記憶體中的位址對應表。相對於各檔案系統所使用的 對應階層不同，所需的位址對應表大小和佔用的記憶體空間也就大不相同，會使 得影響記憶體使用量的因素不僅僅祇有檔案系統中儲存檔案的個數，例如：JFFS2 中類似 node-level 的對應關係，使得 JFFS2 的記憶體使用量是和檔案系統中儲存 的 raw node 個數有絕對的關系，而且影響的效果相當顯著。所以在之後的三種 檔案系統實作位址轉換的段落中，我們會一一的介紹 JFFS2,YAFFS 和 NFTL 中 實踐位址對應表(address translation mapping table)的觀念，並在之後的實驗中，再 借由這些原理來設計實驗範例，來探討這 3 種檔案系統在特定情形和工作量 (workload)下，所使用的記憶體大小和利弊關係。

4.2.1.2 File-system management structure

在這三種記憶體檔案系統中，使用記憶體的地方，除了上一段提到的實現位 址轉換功能所使用的資料結構之外，快閃記憶體檔案系統儲存在記憶體的資料結 構還有哪些呢？扣除一些 read/write 時讀入的使用者的檔案資料之外，其他還有 管理檔案系統所必須的 metadata 資訊。這些 metadata 資訊會紀錄著每個檔案系 統的運作時的即時資訊，例如：JFFS2 中有使用三種以上不同的串列來區別檔案 系統中每個區塊的使用狀態，依照區塊內含無效資料的多寡區分成 clean_list、 dirty_list、very_dirty_list 和 erasable_list 等狀態不同的區塊，方便之後垃圾回收 挑選目標區塊時，能快速區分出較有回收效益的區塊。而這些 metadata 通常是 在檔案系統掛載完畢後，就一定會存在於記憶體的資料結構，不管檔案系統中是 否存有任何的檔案，也就是檔案系統天生擁有的最低記憶體消耗的資料結構，不 過這些 metadata 佔有的記憶體空間差異不大，而且不管在那一種情況中都是消 耗固定的記憶體，不會隨著使用者使用的情況的改變而產生大變化，因此我們對

這部份的探討便不太深入的探究，因為我們對會依照情況改變而有大程度改變的 項目較有興趣。

4.2.1.2 Directory hierarchy structure

在記憶體中的資料結構，還有微詞目錄階層架構的功能，例如:YAFFS 使用 yaffs_object 的資料結構來建構出整個檔案系統的目錄架構。JFFS2 在記憶體中的 資料結構除了位址轉換的功能之外，也提供了類似目錄階層架構的關係，可以使 得檔案系統迅速的找到所屬目錄和檔案在檔案系統中相對映的親子(parent-child) 關係。這也是檔案系統中必須的功能之一，但在 NFTL 只提供了邏輯位址和實體 位址的對應關係，其檔案系統中的目錄結構關係，必須藉由底下搭配的 FAT 和 EXT2 等檔案系統去管理和控制，所以在之後實驗記憶體使用量上的比較，我們 也就必須考量到 NFTL 底下搭配的檔案系統所使用的記憶體量。

4.2.2 File-System Implementations

接下來我們會依序介紹 3 個快閃記憶體檔案系統，是如何實作位址轉換的機 制，以便實現 out-place 策略來管理快閃記憶體的空間。

4.2.2.1 JFFS2

在 JFFS2 中使用的資料結構相當的多，簡單的分類介紹一下。首先是一般常 備在 filesystem 的資料結構，主要是每一個檔案和目錄都會有一個 inode 去表示， 而 JFFS2 會在這些 indoe 的附加資訊中加入 jffs2_indoe_info 的資料結構，其中會 連接著一個 jffs2_full_dirent 的 list 和一個 jffs2_inode_cache，而這個

jffs2_inode_cache 中又會指向一個 jffs2_raw_node_ref 構成的 list。這些 jffs2_raw_node_ref 主要是用來指向儲存在 flash 上 jffs2_raw_inode 和

jffs2_raw_dirent 的實體位址。在檔案系統剛建立的時候，系統會掃描整個快閃記 憶體來建構這些資料結構，再利用這些資料結構來組成系統初期的目錄階層關 係。 JFFS2 為了實作位址轉換的機制，所使用記憶體映成(memory mapping)的關 係，大致上可以分作兩種。一種是當 inode 為開啟的檔案的時候，另一種情形 indoe 是一般目錄。這兩種情況下的對應關係圖，分別為圖表 11 和圖表 12 所表示。

首先當 inode 用來表示 file 時，在 jffs2_indoe_info 中會有一個指向由

jffs2_inode_frag 所構成的 list，當開啟檔案時會利用這個串列(list)建立 frag tree， 而這個 frag tree 是依照所對應的 raw node 的版本(version)大小所建立，所以參照 這個 frag tree 可以建構出擁有最新版本(version)的檔案內容。而每一個

jffs2_raw_node_ref 中的實體位址的偏移量(physical address offset)為何以及被多 少個 frag nodes 參照到，沒被任何 frag node 參照到的 jffs2_full_dnode 便會被刪 除。因此每當檔案更新片段的資料，除了新增一個 jffs2_raw_node_ref 之外，還 要新建對應的 jffs2_node_frag 和 jffs2_full_dnode 這兩個資料結構。(圖表 11)

圖表 11. The JFFS2 structure when open a file.

當 inode 為目錄時，jffs2_indoe_info 中 jffs2_full_dirent 的 list 便是表示著這 個目錄底下所擁有的子目錄或檔案，每一個 jffs2_full_dirent 又會指向一個 jffs2_raw_node_ref，這些 jffs2_raw_node_ref 就指向 flash 中儲存 jffs2_raw_dirent 的實體位址。jffs2_indoe_info 會另外對應到一個 jffs2_full_dnode，再尋線(透過 jffs2_raw_node_ref)可找到對應的 jffs2_raw_inode 的實體位址。這些

jffs2_raw_node_ref 會構成 jffs2_indoe_info 上指向 jffs2_inode_cache 中的 jffs2_raw_node_ref 的串列。 (圖表 12)

圖表 12. The JFFS2 structure of opening directory.

4.2.2.2 YAFFS

YAFFS 儲存在主記憶體上的資料結構主要有 3 種：yaffs_Object, yaffs_Tnode 和 yaffs_Device。Yaffs_Device 是類似 Superblock 的資料結構，用來紀錄整個儲 存裝置的上下對應關係(EX:紀錄對應到的 MTD device 和讀寫所需的運算函 數)。Yaffs_nodes 是 YAFFS 中主要用來處理邏輯位址(logical address)和實體位址 (physical address)之間關係的資料結構(如圖表 13 所示)，每一個檔案可以視為許 多的 yaffs_tnode，而底層 LEVEL 0 的 yaffs_tnode 會指向快閃記憶體中真正儲存 資料的 yaffs_object 的實體位址。

4.2.2.3 NFTL

NFTL在RAM上的資料結構只有NFTLrecond，而NFTLrecond的大小是 固定的佔用 364bytes的memory，其中主要是利用兩張表格(EUNtable和

RepUnitable)來模擬Virtual Unit Chain7進而達到位址轉換的關係，其中EUNtable 是一個logical to physical的表格，紀錄每一個block所屬的串鏈(chain)的起始實體 位址，而ReplUnitTable是一個physical to physical的表格，紀錄每一個在串鏈中 的區塊，以及之後的區塊的實體位址，以維持Virtual Unit Chain的結構。NFTL 管理所有的區塊的對應關係和運作如圖表 14.所示，圖表 14 有兩條virtual unit chain 分別為 4-6-8-5 和 2-0-7-1-3。 圖表 14. NFTL address translation

4.3 Garbage Collection

垃圾回收主要的工作就是回收已經被寫過的快閃記憶體空間，並將這已被寫 過的快閃記憶體空間利用抹除的動作回復到原始可執行寫入動作的狀態。關於垃 圾回收的部份，我們主要關心的是各個檔案系統執行垃圾回收的動作所耗廢掉的 時間，以及所消耗掉的抹除次數和額外的寫入資料。我們還是利用 Postmark 來 作為黑盒子測試的主要方式，再搭配[1]中 Linux 作業系統中常見的檔案分佈的關 係，去調設 Postmark 的參數，將檔案大小設定在最常出現大小範圍內來進行測 試。而白盒子的方法分為兩種：分別為範例一:循序地大檔案寫入(Sequential Write Big file)和範例二:交錯地寫入大檔案和小檔案(Interleaving Write Big/Small file)。

7

Virtual Unit Chain：由一個以上的Virtual Unit所組成，virtual unit則是在RAM中用來對應flash 中的erase unit，實際上virtual unit並不儲存資料，只儲存所對應的erase unit的physical address，即 ReplUnitTable的entry。而Virtual unit chain則是一個logical address指著virtual unit chain的第一個 virtual unit的位置。