MFS文件系統

MFS特性

   Free(GPL)

   通用文件系統，不須要修改上層應用就能夠使用

   能夠在線擴容，體系架構可伸縮性極強。

   部署簡單。

   高可用，可設置任意的文件冗餘程度

   可回收在指定時間內刪除的文件

   提供netapp，emc，ibm等商業存儲的snapshot特性

   google filesystem的一個c實現。

   提供web gui監控接口。

   提升隨機讀或寫的效率

   提升海量小文件的讀寫效率

讀示意圖:

MFS的讀數據過程:
    client當須要一個數據時，首先向master server發起查詢請求；
   管理服務器檢索本身的數據，獲取到數據所在的可用數據服務器位置ip|port|chunkid；
   管理服務器將數據服務器的地址發送給客戶端；
   客戶端向具體的數據服務器發起數據獲取請求；
   數據服務器將數據發送給客戶端；

寫示意圖：

 

MFS的寫數據過程：

   當客戶端有數據寫需求時，首先向管理服務器提供文件元數據信息請求存儲地址（元數據信息如：文件名|大小|份數等）；

   管理服務器根據寫文件的元數據信息，到數據服務器建立新的數據塊；

   數據服務器返回建立成功的消息；

   管理服務器將數據服務器的地址返回給客戶端(chunkIP|port|chunkid)；

   客戶端向數據服務器寫數據；

   數據服務器返回給客戶端寫成功的消息；

   客戶端將這次寫完成結束信號和一些信息發送到管理服務器來更新文件的長度和最後修改時間

MFS的刪除文件過程：

   客戶端有刪除操做時，首先向Master發送刪除信息；

   Master定位到相應元數據信息進行刪除，並將chunk server上塊的刪除操做加入隊列異步清理；

   響應客戶端刪除成功的信號

MFS修改文件內容的過程：

   客戶端有修改文件內容時，首先向Master發送操做信息；

   Master申請新的塊給.swp文件，

   客戶端關閉文件後，會向Master發送關閉信息；

   Master會檢測內容是否有更新，如有，則申請新的塊存放更改後的文件，刪除原有塊和.swp文件塊；

   若無，則直接刪除.swp文件塊。

MFS重命名文件的過程：

   客戶端重命名文件時，會向Master發送操做信息；

   Master直接修改元數據信息中的文件名；返回重命名完成信息；

MFS遍歷文件的過程：

   遍歷文件不須要訪問chunk server，當有客戶端遍歷請求時，向Master發送操做信息；

   Master返回相應元數據信息；

   客戶端接收到信息後顯示

注：

   Master記錄着管理信息，好比：文件路徑|大小|存儲的位置(ip,port,chunkid)|份數|時間等，元數據信息存在於內存中，會按期寫入metadata.mfs.back文件中，按期同步到metalogger，操做實時寫入changelog.*.mfs，實時同步到metalogger中。master啓動將metadata.mfs載入內存，重命名爲metadata.mfs.back文件。

   文件以chunk大小存儲，每chunk最大爲64M，小於64M的，該chunk的大小即爲該文件大小（驗證明際chunk文件略大於實際文件），超過64M的文件將被切分，以每一份（chunk）的大小不超過64M爲原則；塊的生成遵循規則：目錄循環寫入(00-FF 256個目錄循環，step爲2)、chunk文件遞增生成、大文件切分目錄連續。

   Chunkserver上的剩餘存儲空間要大於1GB（Reference Guide有提到），新的數據纔會被容許寫入，不然，你會看到No space left on device的提示，實際中，測試發現當磁盤使用率達到95%左右的時候，就已經不行寫入了，當時可用空間爲1.9GB。

   文件能夠有多份copy，當goal爲1時，文件會被隨機存到一臺chunkserver上，當goal的數大於1時，copy會由master調度保存到不一樣的chunkserver上，goal的大小不要超過chunkserver的數量，不然多出的copy，不會有chunkserver去存。