四、 Flash-Memory-Based File-System Benchmarks
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
了解過 3 種檔案系統的實作之後，我們接下來要研究的是這三種檔案系統再
快閃記憶體上得資料結構和讀/寫的使用的對應大小(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 量較多。
4.1.2 File-System Implementations
了解過檔案系統在儲存體上會存放的各種形式之後，接下來我們會一一介紹 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 空間。
圖表 8. The data structure of JFFS2 stored in flash.
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中使用者區域的部份大都是用來儲存使用者 資料，但根據使用的檔案
NFTL中使用者區域的部份大都是用來儲存使用者 資料，但根據使用的檔案