ubifs & mtd

 

前天晚上在寫完另一篇總結之時，趙XX向我諮詢了關於mtd 和ubifs的相關內容。而我在這方面只是略懂皮毛，所以向他許願共同調查這個方面的知識。
經過昨天一天的調查，最後感覺是有了一定的經驗和基礎了，所以要趕緊記錄下來。
不知道按什麼順序來講述這個方面的內容，那麼還是按照我的疑問過程來一步步解析吧。
Mtd
Mtd的意思是Memory technology device，就是儲存技術裝置的意思，多指flash。但是這個概念在最終解析到核心源碼是，有了一定的改變。
Ubifs
Ubifs 是一個新興的應用於mtd上的有效檔案系統。可以有效組織flash的壞塊和peb的Server Load Balancer，同時提供訪問速度，減小記憶體消耗，具有日誌的功能。是JFFS2的後續增強版。
三．疑問
初識ubifs，相信大家都是從uibfs的操作工具來開始的。通過ubifs的工具可以attach/detach mtd，create/destroy ubi_volume, resize/rename ubi_volume, read/write ubi_volume。在操作的過程中，我的第一個疑問是：
在mtd裝置上存在著partition，在ubi上存在volume，他們之間什麼關係，同時也存在著兩個概念mtd device，ubi device，他們之間的區別和聯絡又是什嗎？
對這個問題的解答，我並沒有從網路獲得明確的答案。所以我轉到對核心的解析上。對於第二個提問，我在核心（2.6.29）中的ubifs.txt上，有了一個大致概念。先說這個，mtd device 代表著物理裝置，這個物理裝置上存在著許多物理塊（nand），這些塊大部分是好的，也有少數是壞塊，所以mtd device 代表著所有的好塊和壞塊。對這些mtd device，核心提供了讀寫等操作。
Ubi device 代表著物理介質上的邏輯裝置。跟mtd device一樣，也有讀寫等操作介面。可是這個裝置在使用者看來是沒有壞塊的，ubi device 負責了壞塊的管理，並且對物理塊進行了新的組織，即使在使用者層看來這是一個串列的讀寫裝置，但是在ubi device中，卻是進行了新的映射。這種映射目的在於負載的均衡。
再說第一個提問。首先是對mtd 部分的解析。以下是結果。
Mtd 在初始化時，會將同一類型的flash劃分成一個mtd device。這個device的大小等於所以晶片容量的總和。這個過程完成後，就會從核心啟動參數或者預設的分區表中獲得分區資訊。最後，將每個分區作為，一個mtd device添加到mtd_tables中。
我們在cat /proc/mtd時，就是返回的mtd_table中的資訊。
指示了整個流程。

這裡有一點重要的是：在parse_mtd_partition的cmdline中一個關鍵點是需要mtd->name = mtd->id，否則parse將返回錯誤結果。這是在開發驅動的時候，應該瞭解的。
另外一個重要結構是：mtd_table。其中儲存了所有的mtd device的資訊。
至此我們知道了mtd 上的partition 最終被作為mtd device儲存到了mtd_table中了。
繼續，ubifs的部分。
這個部分我只能寫一下流程了，畫圖更能說明問題。

從中我們可以看出，最後每個ubi volume又被類比成partition 添加到了mtd_table中了。
因此可以得到一個總體的mtd 和ubi 的關係圖。

每個mtd partition 可以attach 到一個ubi device上，在每個ubi device上又可以建立很多ubi volume，而每個ubi volume又被作為一個mtd device 儲存於mtd table 中。
從核心中我們可以看到mtd的type分為 nor ，nand，ram，rom，ubivolume。
下面是一個詳細的關於使用者空間裝置節點的流程圖。

好了，到這裡，大致的概念已經清楚了。進而產生了第二個問題。
關於ubifs的核心啟動參數的意義都是什嗎？
下面是一個uboot中的核心啟動參數。
Bootargs=console=ttyS0,115200n8 ubi.mtd=4 root=ubi0:rtfs rootfstype=ubifs rw mtdparts=café_nand:200M(part1),300M(part2),400M(part3),500M(part4),-(part5)
其中console部分是定義關於串口的參數，這裡不解釋了。
ubi.mtd=4 指示整個系統的根檔案系統在第四個mtd 上，系統將據此預設把mtd4 attach到ubi0 上。 
root=ubi0:rtfs 指示 根檔案系統在ubi0上的名字叫做rtfs的volume上。注意這裡ubifs的裝置名稱字的寫法，不是以/dev開頭。他的寫法有兩種：
a) 【ubi device名b) 】：【ubi volume名c) 】，d) 例如ubi0:rootfs
e) 【ubi device名f) 】_【ubi volume 編號】，g) 例如ubi0_0
rootfstype=ubifs 指示rootfs的檔案系統類型為ubifs
mtdparts=café_nand:200M(part1),300M(part2),400M(part3),500M(rootfs),-(part5)
定義了物理分區表。格式為
Mtd_id:[-]size[@offset](name)[mask_flag], …,…
其中[]中的代表可有可無項。
Mtd_id 對應於某種類型flash init過程中的name，二者必須相同，才能進行有效分區。
- 表示該分區劃分所有的剩餘空間。
Size 指示當前分區的大小。
@引導offset的開始。
Offset 指示該分區的起始位移量。
()中表示該物理分區（partition）的名字。
Name 表示該物理分區（partition）的名字.
Mask_flag 表示該分區的讀寫屬性。
， 指示還有其他分區。

那麼現在回頭去看例子中的參數含義就明了了。
系統中存在五個partition，在第四個partition上安放著rootfs，而具體的，rootfs存在於第四個partition 對應的ubi0的名字叫做rtfs的volume上。

四．補充
1. 在add_mtd_device中，有一個noitifier的鉤子操作。這樣只要添加了一個mtd device，我們就可通過notifier 獲知並進行相關的操作。實際上，核心也是利用這個鉤子，在每當建立mtd device 時，通過udev 在使用者態的/dev/下，為其建立裝置節點。這個功能或許在以後編寫驅動時能夠滿足某種特殊需求。
2. 在parse_mtd_partition 之處的指點。通常parse_mtd_partition 會跟據 parse 的type 來進行分析，
如果parse_mtd_partition 的返回大於0，說明操作成功了，獲得了分區表。而如果返回小於等於0，說明操作失敗，沒有分區表。這個時候就可以將預先定義好的分區表作為參數傳遞給add_mtd_partition。這樣就實現了使用者預分配分區（固定分區）的功能。
3．始終在核心之中沒有找到關於“ubi.mtd=？”的代碼，所以對該部分的解釋來源於網路，正確與否也依賴於此。
4.當ubi作為模組載入時，一個參數名叫做mtd。此時mtd=？的作用就是將mtd指定的分區attach到最後一個沒被使用的ubi device的索引上。
5. ubifs的resize 代表著保留著的用於坏塊處理的空間可以擴充最多2%的整體空間。詳細需要參考ubifs的開發文檔。
6. ubifs 跟隨他的物理分區，一旦被燒寫大小就固定下來。除非重新進行分區，重新燒寫。
7. 不明白為什麼現在所做的實驗：ubiattach  /dev/ubi_ctrl –m 1 會失敗? 不負責任的解釋：核心版本2.6.26並不是ubifs的穩定版（2.6.30）。

相信後續會有很多問題，但目前先止步於此，畢竟需求是向前的動力。
在調查的過程中，做了許多的實驗，所以這篇總結的底氣還是很足的，因為都是實驗的結果。通過現象看核心，再從核心預測現象，這樣反覆，就成就了印象深刻的結論。
跟趙慧鵬的交流也很快樂，大家都是初學者，同樣提出不一樣的問題，從而促進解析的深入進行。從問題的一點進入，在慢慢擴散，慢慢滲透，不斷從高的層面總結，是這次調查的收穫。