UBIFS檔案系統分析五之重要資料結構

用leeming的話來說，乙個大的工程中，最最核心的往往是資料結構體的定義。所以看**不急著看c檔案，而是主要看document和h檔案，來理解設計者的思路，這樣才能走對路。

1. struct ubi_device

ubi中對於乙個ubi裝置的抽象是以struct ubi_device來定義，其中包括了該ubi裝置的各種資訊。

struct ubi_device __attribute__ ((packed));

3. struct ubi_volume

struct ubi_volume是對ubi裝置上每乙個volume的抽象。

struct ubi_volume u;

6. struct ubi_ec_hdr

我們知道ubifs是乙個wear-level的檔案系統，即均衡損耗。我們就以struct ubi_ec_hdr這個開始重要結構體的介紹。

struct ubi_ec_hdr __attribute__ ((packed));

我們注意其中的乙個成員變數為_be64 ec，ec是什麼，ec就是erase counter。我們知道nandflash是的擦除是有次數限制的，當擦除的次數太多的時候，就會變成壞塊。什麼是均衡損耗，就是在檔案系統的管理下，我們不能對其中的一塊進行過多的擦除操作。

我們來看函式ensure_wear_leveling，它只要是來判斷ubi裝置是否需要進行均衡損耗的相關處理，這兒就有兩個問題了。1.它判斷的依據是什麼。2.它會進行什麼樣的相關來避免對乙個可擦出塊進行過多的擦除操作。

那麼我們先來回答第乙個問題，在wl子系統中，所有的可擦出塊都歸wl子系統來進行管理。這是乙個rb數，我們來其中的每乙個結點。

struct ubi_wl_entry u;

intec;

intpnum;

說白了，wl只關心乙個東西，那麼就是ec的數值。下面是wear_leveling_worker函式中的一段核心**：

e1= rb_entry(rb_first(&ubi->used), struct ubi_wl_entry, u.rb);

e2= find_wl_entry(&ubi->free, wl_free_max_diff);

if (!(e2->ec - e1->ec >= ubi_wl_threshold))

從used中隊裡中取出乙個leb，顯然ec是最小的（每擦除一次，ec值加一），再從free佇列中取出乙個ec值最大的leb。

如果兩個leb的ec差值大於了ubi_wl_threshold，那麼就需要進行wl操作了。

那麼多操作是什麼呢？

err = ubi_eba_copy_leb(ubi, e1->pnum,e2->pnum, vid_hdr);

將內容從乙個leb搬到另外乙個leb中去。

6.struct ubi_vid_hdr

在上面ec頭部中有乙個成員變數是vid_hdr_offset，是指vid_hdr在flash中的偏移量，接著分析第二重要的資料結構struct ubi_vid_hdr。

struct ubi_vid_hdr __attribute__ ((packed));

這其中最重要的成員變數是__be32 vol_id和__be32 lnum。vol_id是標示該leb屬於哪兒乙個volume。lnum是指與該pnum相對於的lnum。對於上層而言，我們操作的是邏輯塊，也就是lnum，但是最終需要將資料寫進pnum中去，在ubi_eba_write_leb函式中有這樣的一句：

pnum = vol->eba_tbl[lnum];

每乙個volume都有乙個eba_tbl，是在掃瞄的時候建立的。如果該lnum沒有影射，那麼呼叫ubi_wl_get_peb來獲得乙個pnum，並相應的修改volume的eba_tbl;

7. struct ubi_scan_volume

struct ubi_scan_volume {

intvol_id;//volume標號

inthighest_lnum;//該volume中的最高邏輯塊標號

intleb_count;//leb數目

intvol_type;//volume型別

intused_ebs;//已用peb數

intlast_data_size;

intdata_pad;

intcompat;

structrb_node rb;//不清楚具體目的，猜想應該是乙個節點的cache，快取的是剛剛訪問的結點

structrb_root root;

這兒主要注意一下上面的structrb_root root變數，這個成員是乙個紅黑樹的根，用來鏈結在掃瞄的過程中發現的屬於該volume的peb。

這個結構體是在掃瞄的過程中讀vid頭部建立起來的關於volume的臨時資訊。

在ubifs-media.h中定義了很多的結構體，下面簡單的解釋一下。

在《a brief 。。。》中講到了，ubifs採用的node-structure。它的所有的資料都是以node的形式處理的。

struct ubifs_ch，其中ch的意思是指common header，是下面的所有結構體的共同部分。

struct ubifs_ino_node，是用來儲存inode結點相關資訊的。

struct ubifs_data_node，用來儲存具體資料的結點。

struct ubifs_trun_node，用來在trunk的時候寫入journal區中的，只存在於journal區中。

struct ubifs_pad_node，用來進行資料填充的。

struct ubifs_sb_node，超結塊結點，用來記載superblock的相關資訊，只存在在superblock 區中。

struct ubifs_mst_node，記錄master結點的資料結構，記載node樹的根結點以及其他資訊。只存在在master area中。

struct ubifs_ref_node ，用於在更新資料的時候寫入journal區，在commit的時候更新index樹和lpt樹，只存在在journal區中。

struct ubifs_idx_node，idx結點的頭部，關於idx結點，請參考《a briefintroduction to design of ubifs》，只存在在main區中。

struct ubifs_branch，idx結點中的分支。

struct ubifs_cs_node，cs = commit start，用於在journal中表示一次commit的開始，只存在在journal區中。一次commit由乙個ubifs_cs_node 和若干ubifs_ref_node 組成。

struct ubifs_orph_node ，用於在orphan區中記錄相關資訊的結點，關於orphan請參考《a brief introduction to designof ubifs》。

UBIFS檔案系統分析五之重要資料結構

hadoop檔案系統分析

Yaffs 檔案系統分析

檔案 FAT檔案系統分析

UBIFS檔案系統分析五之重要資料結構

hadoop檔案系統分析

Yaffs 檔案系統分析

檔案 FAT檔案系統分析

相關推薦