分布式文件系統（Distributed File System）是指文件系統管理的物理存儲資源不一定直接連接在本地節點上，而是通過計算機網絡與節點相連，分布式文件系統的實際基於客戶機/服務器模式。目前常見的分布式文件系統有很多種，比如Hadoop、Moosefs、HDFS、FastDFS、PNFS(Parallel NFS）、Lustre、TFS、GFS等等一系列。在眾多的分布式文件系統解決方案中，MFS是搭建比較簡單、使用起來也不需要過多的修改web程序，非常方便。
一、MooseFS是什么
MooseFS(即Moose File System，簡稱MFS)是一個具有容錯性的網絡分布式文件系統，它將數據分散存放在多個物理服務器或單獨磁盤或分區上，確保一份數據 有多個備份副本，對於訪問MFS的客戶端或者用戶來說，整個分布式網絡文件系統集群看起來就像一個資源一樣，也就是說呈現給用戶的是一個統一的資源。 MooseFS就相當於UNIX的文件系統（類似ext3、ext4、nfs），它是一個分層的目錄樹結構。 MFS存儲支持POSIX標准的文件屬性（權限，最后訪問和修改時間），支持特殊的文件，如塊設備，字符設備，管道、套接字、鏈接文件（符合鏈接、硬鏈接）； MFS支持FUSE(用戶空間文件系統Filesystem in Userspace，簡稱FUSE），客戶端掛載后可以作為一個普通的Unix文件系統使用MooseFS。 MFS可支持文件自動備份的功能，提高可用性和高擴展性。MogileFS不支持對一個文件內部的隨機或順序讀寫，因此只適合做一部分應用，如圖片服務，靜態HTML服務、 文件服務器等，這些應用在文件寫入后基本上不需要對文件進行修改，但是可以生成一個新的文件覆蓋原有文件。
二、MooseFS的特性
1）高可靠性，每一份數據可以設置多個備份（多分數據），並可以存儲在不同的主機上 2）高可擴展性，可以很輕松的通過增加主機的磁盤容量或增加主機數量來動態擴展整個文件系統的存儲量 3）高可容錯性，可以通過對mfs進行系統設置，實現當數據文件被刪除后的一段時間內，依舊存放於主機的回收站中，以備誤刪除恢復數據 4）高數據一致性，即使文件被寫入、訪問時，依然可以輕松完成對文件的一致性快照 5）通用文件系統，不需要修改上層應用就可以使用（那些需要專門api的dfs很麻煩！）。 6）可以在線擴容，體系架構可伸縮性極強。（官方的case可以擴到70台了！） 7）部署簡單。（sa們特別高興，領導們特別happy！） 8）可回收在指定時間內刪除的文件，即可以設置刪除文件的空間回收時間（"回收站"提供的是系統級別的服務，不怕誤操作了，提供類似oralce 的閃回等 高級dbms的即時回滾特性！）,命令"mfsgettrashtime filename" 9)提供web gui監控接口。 10)提高隨機讀或寫的效率（有待進一步證明）。 11)提高海量小文件的讀寫效率（有待進一步證明）
三、MooseFS的優點
1）部署簡單，輕量、易配置、易維護 2）易於擴展，支持在線擴容，不影響業務，體系架構可伸縮性極強（官方的case可以擴到70台） 3）通用文件系統，不需要修改上層應用就可以使用（比那些需要專門api的dfs方便多了）。 4）以文件系統方式展示:如存圖片，雖然存儲在chunkserver上的數據是二進制文件，但是在掛載mfs的client端仍舊以圖片文件形式展示，便於數據備份 5）硬盤利用率高。測試需要較大磁盤空間 6）可設置刪除的空間回收時間，避免誤刪除文件丟失就恢復不及時影響業務 7）系統負載，即數據讀寫分配到所有的服務器上 8）可設置文件備份的副本數量，一般建議3份，未來硬盤容量也要是存儲單份的容量的三倍
四、MooseFS的缺點
1）master目前是單點（雖然會把數據信息同步到備份服務器，但是恢復需要時間，因此，會影響上線，針對這個問題， 可以通過DRBD+Keeaplived方案或者DRBD+Inotify方案解決），master和backup之間的同步，類似mysql的主從不同。 2）master服務器對主機的內存要求略高 3）默認metalogger復制元數據時間較長（可調整）
五、MooseFS文件系統架構組成及原理
MFS架構圖
MFS文件的讀寫流程圖
---------------------------------------------------------MFS讀寫處理過程--------------------------------------------------------
一、MFS讀取數據步驟：
1）客戶端向元數據服務器發出請求
2）元數據服務器把所需數據存放的位置(Chunk Server 的IP地址及Chunk編號）告知客戶端
3）客戶端向已知Chunk Server請求發送數據
4）客戶端取得所需數據
數據傳輸並不通過元數據服務器，這既減輕了元數據服務器的壓力，同時也大大增加了
整個系統的吞吐能力，在多個客戶端讀取數據時，讀取點(Chunk Server)有可能被分散到不同
的服務器
二、MFS寫入數據步驟：
1）客戶端向元數據服務器發送寫入請求
2）元數據服務器與Chunk Server進行交互如下：
1）元數據服務器指示在某些Chunk Server創建分塊Chunks
2）Chunk Server告知元數據服務器，步驟(1)的操作成功
3）元數據服務器告知客戶端，你可以在哪個Chunk Server的哪個Chunks寫入數據
4）向指定的Chunk Server寫入數據
5）與其他Chunk Server進行數據同步，同步的服務器依據設定的副本數而定，副本為2，則需同步一個ChunkServer
6）Chunk Sever之間同步成功
7）Chunk Server告知客戶端數據寫入成功
8）客戶端告知元數據服務器本次寫入完畢
三、MFS的刪除文件過程
1）客戶端有刪除操作時，首先向Master發送刪除信息；
2）Master定位到相應元數據信息進行刪除，並將chunk server上塊的刪除操作加入隊列異步清理；
3）響應客戶端刪除成功的信號
四、MFS修改文件內容的過程
1）客戶端有修改文件內容時，首先向Master發送操作信息；
2）Master申請新的塊給.swp文件，
3）客戶端關閉文件后，會向Master發送關閉信息；
4）Master會檢測內容是否有更新，若有，則申請新的塊存放更改后的文件，刪除原有塊和.swp文件塊；
5）若無，則直接刪除.swp文件塊。
五、MFS重命名文件的過程
1）客戶端重命名文件時，會向Master發送操作信息；
2）Master直接修改元數據信息中的文件名；返回重命名完成信息；
六、MFS遍歷文件的過程
1）遍歷文件不需要訪問chunk server，當有客戶端遍歷請求時，向Master發送操作信息；
2）Master返回相應元數據信息；
3—— 客戶端接收到信息后顯示
需要注意：
1）Master記錄着管理信息，比如：文件路徑|大小|存儲的位置(ip,port,chunkid)|份數|時間等，元數據信息存在於內存中，會定期寫入metadata.mfs.back文件中，
定期同步到metalogger，操作實時寫入changelog.*.mfs，實時同步到metalogger中。master啟動將metadata.mfs載入內存，重命名為metadata.mfs.back文件。
2）文件以chunk大小存儲，每chunk最大為64M，小於64M的，該chunk的大小即為該文件大小（驗證實際chunk文件略大於實際文件），超過64M的文件將被切分，以每一
份（chunk）的大小不超過64M為原則；塊的生成遵循規則：目錄循環寫入(00-FF 256個目錄循環，step為2)、chunk文件遞增生成、大文件切分目錄連續。
3）Chunkserver上的剩余存儲空間要大於1GB（Reference Guide有提到），新的數據才會被允許寫入，否則，你會看到No space left on device的提示，實際中，
測試發現當磁盤使用率達到95%左右的時候，就已經不行寫入了，當時可用空間為1.9GB。
4）文件可以有多份copy，當goal為1時，文件會被隨機存到一台chunkserver上，當goal的數大於1時，copy會由master調度保存到不同的chunkserver上，goal的大小
不要超過chunkserver的數量，否則多出的copy，不會有chunkserver去存。
MFS組件
1）管理服務器managing server簡稱（master）： 這個組件的角色是管理整個mfs文件系統的主服務器，除了分發用戶請求外，還用來存儲整個文件系統中每個數據文件的metadata信息，metadate（元數據）信息包括 文件（也可以是目錄，socket，管道，塊設備等）的大小，屬性，文件的位置路徑等，很類似lvs負載均衡的主服務器，不同的是lvs僅僅根據算法分發請求，而master 根據內存里的metadata信息來分發請求，內存的信息會被實時寫入到磁盤，這個master只能由一台處於激活的狀態 2）元數據備份服務器Metadata backup servers（簡稱metalogger或backup）： 這個組件的作用是備份管理服務器master的變化的metadata信息日志文件，文件類型為changelog_ml.*.mfs。以便於在管理服務器出問題時，可以經過簡單的操作即可 讓新的主服務器進行工作。這類似mysql主從同步，只不過它不像mysql從庫那樣在本地應用數據，而只是接受主服務器上文寫入時記錄的文件相關的metadata信息，這 個backup，可以有一台或多台，它很類似lvs從負載均衡服務器 3）數據存儲服務器組data servers（chunk servers）簡稱data： 這個組件就是真正存放數據文件實體的服務器了，這個角色可以有多台不同的物理服務器或不同的磁盤及分區來充當，當配置數據的副本多於一份時，據寫入到一個數 據服務器后，會根據算法在其他數據服務器上進行同步備份。這有點類似lvs集群的RS節點 4）客戶機服務器組（client servers）簡稱client： 這個組件就是掛載並使用mfs文件系統的客戶端，當讀寫文件時，客戶端首先會連接主管理服務器獲取數據的metadata信息，然后根據得到的metadata信息，訪問數據服 務器讀取或寫入文件實體，mfs客戶端通過fuse mechanism實現掛載mfs文件系統的，因此，只有系統支持fuse，就可以作為客戶端訪問mfs整個文件系統，所謂的客戶端 並不是網站的用戶，而是前端訪問文件系統的應用服務器，如web -------------------MFS 文件系統結構包含4種角色---------------------- 1）管理服務器 Master Server（Master） 2）元數據日志服務器 Metalogger Server(Metalogger) 3）數據存儲服務器 Data Servers (Chunkservers) 4）客戶端 Client ---------------MFS的4種角色作用如下--------------- 1）Master管理服務器 有時也稱為元數據服務器，負責管理各個數據存儲服務器，調度文件讀寫，回收文件空間以及恢復多節點拷貝。目前MFS只支持一個元數據服務器master，這是一個單點故障， 需要一個性能穩定的服務器來充當。希望今后MFS能支持多個master服務器，進一步提高系統的可靠性。 2）Metalogger元數據日志服務器 負責備份管理服務器的變化日志文件，文件類型為changelog_ml.*.mfs，以便於在管理服務器出問題時接替其進行工作。元數據日志服務器是mfsl.6以后版本新增的服務， 可以把元數據日志保留在管理服務器中，也可以單獨存儲在一台服務器中。為保證數據的安全性和可靠性，建議單獨用一台服務器來存放元 數據日志。需要注意的是，元 數據日志守護進程跟管理服務器在同一個服務器上，備份元數據日志服務器作為它的客戶端，從管理服務器取得日志文件進行備份。 3）Chunkserver數據存儲服務器(推薦至少兩台chunkserver) 數據存儲服務器是真正存儲用戶數據的服務器，負責連接管理服務器,聽從管理服務器調度,提供存儲空間，並為客戶提供數據傳輸。在存儲文件時，首先把文件分成塊， 然后將這些塊在數據存儲服務器之間互相復制（復制份數手工指定，建議設置副本數為3），數據服務器可以是多個，並且數量越多，可使用的"磁盤空間"越小，可靠性也越高。 同時，數據存儲服務器還負責連接管理服務器，聽從管理服務器調度，並為客戶提供數據傳輸。數據存儲服務器可以有多個，並且數量越多，可靠性越高，MFS可用的磁盤空間也越大。 4）Client客戶端 通過fuse內核接口掛接遠程管理服務器上所管理的數據存儲服務器，使共享的文件系統和使用本地Linux文件系統的效果看起來是一樣的。 ----------------MFS內部運行機制------------------- 1）客戶端請求訪問存儲，請求發送到了MFS Master 2）MFS Master根據客戶訪問的請求，查詢所需要的文件分布在那些服務器上 3）客戶端直接和存儲服務器進行數據存儲和讀寫 ---------------MFS的應用場景--------------- 1）大規模高並發的線上數據存儲及訪問（小文件，大文件都適合） 2）大規模的數據處理，如日志分析，小文件強調性能不用HDFS。 有大多的應用不適合分布式文件系統，不建議大家為了使用而使用。盡量在前端加cache應用，而不是一味的 擴充文件系統
六、為什么要使用MFS
由於用戶數量的不斷攀升,對訪問量大的應用實現了可擴展、高可靠的集群部署（即lvs+keepalived的方式），但仍然有用戶反饋訪問慢的問題。通過排查個服務器的情況， 發現問題的根源在於共享存儲服務器NFS。在我這個網絡環境里，N個服務器通過NFS方式共享一個服務器的存儲空間，使得NFS服務器不堪重負。察看系統日志，全是NFS服 務超時之類的報錯。一般情況下，當NFS客戶端數目較小的時候，NFS性能不會出現問題；一旦NFS服務器數目過多，並且是那種讀寫都比較頻繁的操作，所得到的結果就不 是我們所期待的。
NFS缺陷（如下在web集群中使用NFS共享文件）
NFS雖然使用簡單，但當NFS客戶端訪問量大時，通過NFS方式共享一個服務器的存儲空間，使得NFS服務器不堪重負，並且執行讀寫都比較頻繁的操作會出現 意外的錯誤，對於高可靠的集群部署是有挑戰的。這種架構除了性能問題而外，還存在單點故障，一旦這個NFS服務器發生故障，所有靠共享提供數據的應用 就不再可用，盡管用rsync方式同步數據到另外一個服務器上做NFS服務的備份，但這對提高整個系統的性能毫無幫助。基於這樣一種需求，我們需要對NFS服 務器進行優化或采取別的解決方案，然而優化並不能對應對日益增多的客戶端的性能要求，因此唯一的選擇只能是采取別的解決方案了； 通過調研，分布式文件系統是一個比較合適的選擇。采用分布式文件系統后，服務器之間的數據訪問不再是一對多的關系（1個NFS服務器，多個NFS客戶端）， 而是多對多的關系，這樣一來，性能大幅提升毫無問題。 選擇MFS分布式文件系統來作為共享存儲服務器，主要考慮如下： 1）實施起來簡單。MFS的安裝、部署、配置相對於其他幾種工具來說，要簡單和容易得多。看看lustre 700多頁的pdf文檔，讓人頭昏吧。 2）不停服務擴容。MFS框架做好后，隨時增加服務器擴充容量；擴充和減少容量皆不會影響現有的服務。注：hadoop也實現了這個功能。 3）恢復服務容易。除了MFS本身具備高可用特性外，手動恢復服務也是非常快捷的
MFS分布式文件系統環境部署記錄
1）master-server元數據服務器上的操作記錄
1）綁定host，關閉防火牆
[root@master-server ~]# vim /etc/hosts
182.48.115.233 master-server
182.48.115.235 metalogger
182.48.115.236 chunkServer1
182.48.115.237 chunkServer1
最好是關閉防火牆（selinux也要關閉，執行setenforce 0）
[root@master-server ~]# /etc/init.d/iptables stop
2）創建mfs用戶和組
[root@master-server ~]# useradd mfs -s /sbin/nologin
3）編譯安裝mfs
百度下載地址：https://pan.baidu.com/s/1slS7JK5 （提取密碼：park）
[root@master-server ~]# wget https://fossies.org/linux/misc/legacy/moosefs-3.0.91-1.tar.gz
[root@master-server ~]# tar -zvxf moosefs-3.0.91-1.tar.gz
[root@master-server ~]# cd moosefs-3.0.91
[root@master-server moosefs-3.0.91]# ./configure --prefix=/usr/local/mfs --with-default-user=mfs --with-default-group=mfs
[root@master-server moosefs-3.0.91]# make && make install
[root@master-server moosefs-3.0.91]# cd /usr/local/mfs/etc/mfs
[root@master-server mfs]# ls
mfschunkserver.cfg.sample mfshdd.cfg.sample mfsmetalogger.cfg.sample mfstopology.cfg.sample
mfsexports.cfg.sample mfsmaster.cfg.sample mfsmount.cfg.sample
4）master服務器需要以下文件：
mfsmaster.cfg 主文件
mfsexports.cfg mfs掛載權限設置，參考NFS文件系統中的exports.cfg
mfstopology.cfg 機架感知
下面開始修改配置文件
[root@master-server mfs]# cp -a mfsmaster.cfg.sample mfsmaster.cfg
[root@master-server mfs]# cp -a mfstopology.cfg.sample mfstopology.cfg
[root@master-server mfs]# cp -a mfsexports.cfg.sample mfsexports.cfg
[root@master-server mfs]# vim mfsexports.cfg
.......
182.48.115.0/27 / rw,alldirs,maproot=0
* . rw
設置解釋：
第一個設置，代表讓182.48.115.0網段機器可以掛載mfs的根分區；如果將"/"改為"."符號則表示允許訪問所有
注意這里機器的netmask是255.255.255.224，所以子網掩碼是27位，如果是255.255.255.0，那么掩碼就是24位。
第二個設置是允許客戶端掛載使用回收站功能。如果決定了掛載mfsmeta，那么一定要在mfsmaster的mfsexport.cfg文件中添加這條記錄：
權限說明：
ro 只讀模式
rw 讀寫模式
alldirs 允許掛載任何指定的子目錄
maproot 映射為root，還是指定的用戶
[root@master-server mfs]# cd ../../var/mfs/
[root@master-server mfs]# ls
metadata.mfs.empty
[root@master-server mfs]# cp -a metadata.mfs.empty metadata.mfs
[root@master-server mfs]# chown -R mfs:mfs /usr/local/mfs
5）啟動mfsmaster命令：
[root@master-server mfs]# /usr/local/mfs/sbin/mfsmaster start //可以使用/usr/local/mfs/sbin/mfsmaster -a 命令進行啟動，這種方式一般可用於修復性啟動。
open files limit has been set to: 16384
working directory: /usr/local/mfs/var/mfs
lockfile created and locked
initializing mfsmaster modules ...
exports file has been loaded
topology file has been loaded
loading metadata ...
metadata file has been loaded
no charts data file - initializing empty charts
master <-> metaloggers module: listen on *:9419
master <-> chunkservers module: listen on *:9420
main master server module: listen on *:9421
mfsmaster daemon initialized properly
[root@master-server mfs]# ps -ef|grep mfs
mfs 31312 1 2 10:58 ? 00:00:00 /usr/local/mfs/sbin/mfsmaster start
root 31314 24958 0 10:58 pts/0 00:00:00 grep mfs
[root@master-server ~]# lsof -i:9420 //防火牆如果開啟了，需要開放9420端口訪問
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
mfsmaster 31312 mfs 9u IPv4 108440 0t0 TCP *:9420 (LISTEN)
-------------------------------------------------------------------------------------
mfsmaster相關啟動命令
# /usr/local/mfs/sbin/mfsmaster start|stop|restart|reload|info|test|kill
將mfsmaster啟動命令軟鏈接到/etc/init.d下面
[root@master-server mfs]# ln -s /usr/local/mfs/sbin/mfsmaster /etc/init.d/mfsmaster
[root@master-server mfs]# /etc/init.d/mfsmaster statrt/stop/status/reload/restart //還可以使用/etc/init.d/mfsmaster -a命令進行啟動
-------------------------------------------------------------------------------------
master管理節點的數據存放在/usr/local/mfs/var/mfs/目錄下
6）啟動和停止Web GUI
[root@master-server mfs]# /usr/local/mfs/sbin/mfscgiserv start
lockfile created and locked
starting simple cgi server (host: any , port: 9425 , rootpath: /usr/local/mfs/share/mfscgi)
[root@master-server mfs]# ps -ef|grep mfscgiserv
root 31352 1 0 11:01 ? 00:00:00 /usr/bin/python /usr/local/mfs/sbin/mfscgiserv
root 31356 24958 0 11:02 pts/0 00:00:00 grep mfscgiserv
[root@master-server mfs]# lsof -i:9425
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
mfscgiser 31352 root 3u IPv4 105260 0t0 TCP *:9425 (LISTEN)
相關啟動命令
[root@master-server mfs]# /usr/local/mfs/sbin/mfscgiserv start/stop/status/restart/reload
訪問Web GUI方式（如果打開了防火牆，防火牆里開放9245端口訪問），訪問地址是http://182.48.115.233:9425
mfscgiserv 是用python寫的一個監控MFS狀態的web界面，監聽端口是9425，必須在master（管理服務器上）上啟動。 常用的參數： -h 幫助信息 -H 綁定的IP，默認為0.0.0.0 -P 綁定端口號，默認是9425 -R mfscgi的root路徑，默認是/usr/local/mfs/share/mfscgi -f 運行HTTP服務器，-f 表示在前台運行，-v表示請求的日志發往標准的錯誤設備 mfscgiserv監控圖有8個部分組成： info 這個部分顯示了MFS的基本信息。 Servers 列出現有的ChunkServer。 Disks 列出每一台ChunkServer的磁盤目錄以及使用量 Exports 列出共享的目錄，既可以被掛載的目錄 mounts 顯示被掛載的情況。 Openrations 顯示正在執行的操作。 Master Charts 顯示Master server的操作情況，包括讀取，寫入，創建目錄，刪除目錄等消息。 Server Charts 顯示ChunkServer的操作情況，數據傳輸率以及系統狀態等信息。
訪問的時候,出現上面界面，提示找不到master主機。莫慌！在DNS解析欄里輸入master管理節點的主機名即可
2）chunkServer數據儲存節點上的操作記錄（在chunkServer1和chunkServer2上都要操作）
1）關閉防火牆（selinux也要關閉，執行setenforce 0） [root@chunkServer1 ~]# /etc/init.d/iptables stop 2）創建mfs用戶和組 [root@chunkServer1 ~]# useradd mfs -s /sbin/nologin 3）編譯安裝mfs（下載地址在上面已經提到） [root@chunkServer1 ~]# yum install -y gcc c++ zlib-devel [root@chunkServer1 ~]# tar -zxvf moosefs-3.0.91-1.tar.gz [root@chunkServer1 ~]# cd moosefs-3.0.91 [root@chunkServer1 moosefs-3.0.91]# ./configure --prefix=/usr/local/mfs --with-default-user=mfs --with-default-group=mfs [root@chunkServer1 moosefs-3.0.91]# make && make install [root@chunkServer1 moosefs-3.0.91]# cd /usr/local/mfs/etc/mfs/ [root@chunkServer1 mfs]# ls mfschunkserver.cfg.sample mfsexports.cfg.sample mfshdd.cfg.sample mfsmaster.cfg.sample mfsmetalogger.cfg.sample mfstopology.cfg.sample 4）chunkserver配置文件如下： mfschunkserver.cfg 這個是mfschunkserver配置文件 mfshdd.cfg 這個是mfschunkserver上的分區，必須是獨立分區！ [root@chunkServer1 mfs]# cp mfschunkserver.cfg.sample mfschunkserver.cfg [root@chunkServer1 mfs]# vim mfschunkserver.cfg ....... MASTER_HOST = 182.48.115.233 //這個填寫master管理節點的ip或主機名 MASTER_PORT = 9420 [root@chunkServer1 mfs]# cp mfshdd.cfg.sample mfshdd.cfg [root@chunkServer1 mfs]# vim mfshdd.cfg //在文件尾行添加下面兩行內容 ....... # mount points of HDD drives /usr/local/mfsdata //由於mfschunkserver上的分區需要是獨立分區！所以這里最好配置成獨立分區。比如/data （df -h命令查看，/data要是獨立分區） [root@chunkServer1 mfs]# mkdir /usr/local/mfsdata //這個是數據的真實存放目錄。里面存放的是數據的chunks塊文件 [root@chunkServer1 mfs]# chown -R mfs:mfs /usr/local/mfsdata/ [root@chunkServer1 mfs]# cd ../../var/mfs/ [root@chunkServer1 mfs]# ls metadata.mfs.empty [root@chunkServer1 mfs]# cp metadata.mfs.empty metadata.mfs [root@chunkServer1 mfs]# chown -R mfs:mfs /usr/local/mfs 5）啟動chunkserver [root@chunkServer1 mfs]# ln -s /usr/local/mfs/sbin/mfschunkserver /etc/init.d/mfschunkserver [root@chunkServer1 mfs]# /etc/init.d/mfschunkserver start open files limit has been set to: 16384 working directory: /usr/local/mfs/var/mfs lockfile created and locked setting glibc malloc arena max to 4 setting glibc malloc arena test to 4 initializing mfschunkserver modules ... hdd space manager: path to scan: /usr/local/mfsdata/ hdd space manager: start background hdd scanning (searching for available chunks) main server module: listen on *:9422 no charts data file - initializing empty charts mfschunkserver daemon initialized properly [root@chunkServer1 mfs]# ps -ef|grep mfs mfs 13843 1 1 13:30 ? 00:00:00 /etc/init.d/mfschunkserver start root 13853 4768 0 13:31 pts/0 00:00:00 grep mfs [root@chunkServer1 mfs]# lsof -i:9422 #防火牆開啟這個端口的訪問 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME mfschunks 13843 mfs 11u IPv4 54792 0t0 TCP *:9422 (LISTEN) 其他相關命令 [root@chunkServer1 mfs]# /etc/init.d/mfschunkserver start/stop/restart/status/reload
3）metalogger元數據日志服務器操作記錄
1）關閉防火牆（selinux也要關閉） [root@metalogger ~]# setenforce 0 [root@metalogger ~]# /etc/init.d/iptables stop 2）創建mfs用戶和組 [root@metalogger ~]# useradd mfs -s /sbin/nologin 3）編譯安裝mfs [root@metalogger ~]# yum install -y gcc c++ zlib-devel [root@metalogger ~]# tar -zvxf moosefs-3.0.91-1.tar.gz [root@metalogger ~]# cd moosefs-3.0.91 [root@metalogger moosefs-3.0.91]# ./configure --prefix=/usr/local/mfs --with-default-user=mfs --with-default-group=mfs [root@metalogger moosefs-3.0.91]# make && make install 4）mfsmetalogger.cfg文件配置 [root@metalogger moosefs-3.0.91]# cd /usr/local/mfs/etc/mfs/ [root@metalogger mfs]# ls mfschunkserver.cfg.sample mfsexports.cfg.sample mfshdd.cfg.sample mfsmaster.cfg.sample mfsmetalogger.cfg.sample mfstopology.cfg.sample [root@metalogger mfs]# cp mfsmetalogger.cfg.sample mfsmetalogger.cfg [root@metalogger mfs]# vim mfsmetalogger.cfg ...... META_DOWNLOAD_FREQ = 1 MASTER_HOST = 182.48.115.233 #如果是單機環境的話，這個不能為localhost或127.0.0.1，要使用對外IP MASTER_PORT = 9419 參數解釋： META_DOWNLOAD_FREQ 表示源數據備份下載請求頻率，這里設置為1小時。默認為24小時，即每隔一天從元數據服務器(MASTER)下載一個metadata.mfs.back 文件。 當元數據服務器關閉或者出故障時，matedata.mfs.back 文件將消失，那么要恢復整個mfs,則需從metalogger 服務器取得該文件。請特別注意這個文件，它與日志 文件（即changelog_ml.0.mfs文件）一起，才能夠恢復整個被損壞的分布式文件系統。元數據日志服務器的備份數據存放目錄是/usr/local/mfs/var/mfs/。 [root@metalogger mfs]# cd ../../var/mfs/ [root@metalogger mfs]# ls metadata.mfs.empty [root@metalogger mfs]# cp metadata.mfs.empty metadata.mfs [root@metalogger mfs]# chown -R mfs:mfs /usr/local/mfs 5）啟動metalogger節點服務 [root@metalogger mfs]# ln -s /usr/local/mfs/sbin/mfsmetalogger /etc/init.d/mfsmetalogger [root@metalogger mfs]# /etc/init.d/mfsmetalogger start open files limit has been set to: 4096 working directory: /usr/local/mfs/var/mfs lockfile created and locked initializing mfsmetalogger modules ... mfsmetalogger daemon initialized properly [root@metalogger mfs]# ps -ef|grep mfs mfs 9353 1 1 14:22 ? 00:00:00 /etc/init.d/mfsmetalogger start root 9355 3409 0 14:22 pts/0 00:00:00 grep mfs [root@metalogger mfs]# lsof -i:9419 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME mfsmetalo 9353 mfs 8u IPv4 38278 0t0 TCP 182.48.115.235:37237->182.48.115.233:9419 (ESTABLISHED) 其他相關啟動命令 [root@metalogger mfs]# /etc/init.d/mfsmetalogger start/stop/status/restart/reload
接着再看看Web GUI訪問頁面（可以reload 重載mfscgiserv服務）
4）mfs client客戶端上的操作記錄
1）mfs client安裝依賴與系統包fuse，通過yum方式安裝（也可以源碼安裝）
[root@clinet-server ~]# yum -y install fuse fuse-devel
2）創建mfs用戶和組
[root@clinet-server ~]# useradd mfs -s /sbin/nologin
3）編譯安裝mfs
[root@clinet-server ~]# yum install -y gcc c++ zlib-devel
[root@clinet-server ~]# tar -zvxf moosefs-3.0.91-1.tar.gz
[root@clinet-server ~]# cd moosefs-3.0.91
[root@clinet-server moosefs-3.0.91]# ./configure --prefix=/usr/local/mfs --with-default-user=mfs --with-default-group=mfs --enable-mfsmount
[root@clinet-server moosefs-3.0.91]# make && make install
4）創建mfs掛載目錄
[root@clinet-server ~]# mkdir /mnt/mfs //這個是掛載的數據目錄，掛載目錄可以在客戶機上任意定義
[root@clinet-server ~]# mkdir /mnt/mfsmeta //這個是掛載的回收站目錄
5）mfs client 掛載命令
[root@clinet-server ~]# /usr/local/mfs/bin/mfsmount /mnt/mfs -H 182.48.115.233 //掛載MFS文件系統的根目錄到本機的/mnt/mfs下
mfsmaster accepted connection with parameters: read-write,restricted_ip,admin ; root mapped to root:root
[root@clinet-server ~]# /usr/local/mfs/bin/mfsmount -m /mnt/mfsmeta/ -H 182.48.115.233 //掛載MFS文件系統的mfsmeta，使用回收站功能
mfsmaster accepted connection with parameters: read-write,restricted_ip
6）查看
[root@clinet-server ~]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/VolGroup-lv_root
8.3G 3.8G 4.1G 49% /
tmpfs 499M 228K 498M 1% /dev/shm
/dev/vda1 477M 35M 418M 8% /boot
/dev/sr0 3.7G 3.7G 0 100% /media/CentOS_6.8_Final
182.48.115.233:9421 16G 2.7G 14G 17% /mnt/mfs
mount查看
[root@clinet-server ~]# mount
/dev/mapper/VolGroup-lv_root on / type ext4 (rw)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
tmpfs on /dev/shm type tmpfs (rw,rootcontext="system_u:object_r:tmpfs_t:s0")
/dev/vda1 on /boot type ext4 (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
gvfs-fuse-daemon on /root/.gvfs type fuse.gvfs-fuse-daemon (rw,nosuid,nodev)
/dev/sr0 on /media/CentOS_6.8_Final type iso9660 (ro,nosuid,nodev,uhelper=udisks,uid=0,gid=0,iocharset=utf8,mode=0400,dmode=0500)
182.48.115.233:9421 on /mnt/mfs type fuse.mfs (rw,nosuid,nodev,allow_other)
182.48.115.233:9421 on /mnt/mfsmeta type fuse.mfsmeta (rw,nosuid,nodev,allow_other)
mfsmount是本地文件系統代理，掛接FUSE，監聽文件系統IO。
mfsmout向master獲取chunk信息，向mfschunkserver發出讀寫數據的命令，chunkserver是磁盤IO的執行者。mfsmount是用戶發出IO請求的命令接收者，master是
mfs所有chunk和node信息的維護者。
在掛載目錄/mnt/mfs下的文件就會通過master管理節點放到chunkserver上，並且是被分成多個塊放到各個chunkserver上的；可以再其他的clinet機器上掛載MFS，那么掛載點里的
文件都是同步共享的。這樣當一台或多台chunkserver宕機或出現故障時（只要不是全部出現故障），對於clinet端來說，共享MFS數據都是不受影響的。
到掛載目錄/mnt/mfs下，就可以查看到MFS文件系統根目錄下的內容了
[root@clinet-server ~]# cd /mnt/mfs
[root@clinet-server mfs]# ls
hqsb huanqiu ip_list
[root@clinet-server mfs]# echo "123123123" > test
[root@clinet-server mfs]# ls
hqsb huanqiu ip_list test
--------------------------------------------------------------------------------
卸載的話，直接使用命令：
[root@clinet-server ~]# umount /mnt/mfs
[root@clinet-server ~]# umount /mnt/mfsmeta
卸載后，在客戶機上的掛載目錄下就什么內容都查看不到了
[root@clinet-server ~]# cd /mnt/mfs
[root@clinet-server mfs]# ls
[root@clinet-server mfs]#
---------------------------------------------------------------------------------
5）MFS日常操作（都在client端下操作）
1->回收站功能
mfs文件系統是正規的mfs掛載系統，里面包含了所有的mfs存儲的文件與目錄。 mfsmeta文件系統是mfs提供用於輔助的文件系統，相當於windows的回收站。 如上，在clinet端啟動管理服務器進程時，用了一個-m選項，這樣可以掛載一個輔助的文件系統mfsmeta，輔助文件系統可以在如下兩個方面恢復丟失的數據： 1）MFS卷上誤刪除了文件，而此文件又沒有過垃圾文件存放期。 2）為了釋放磁盤空間而刪除或者移動的文件，當需要恢復這些文件時，文件又沒有過垃圾文件的存放期。 要使用MFS輔助文件系統，可以執行如下指令： # mfsmount -m /mnt/mfsclient -H mfsmaster //回收站目錄掛載前面已操作 需要注意的是，如果決定了掛載mfsmeta，那么一定要在mfsmaster的mfsexport.cfg文件中添加下面這條記錄（前面已提到）： * . rw 掛載文件系統就可以執行所所有標准的文件操作了。如創建，刪除，復制，重命名文件等。MFS由於是一個網絡文件系統，所以操作進度比本地的偏慢。 需要注意的是，每個文件都可以存儲為多個副本，在這種情況下，每一個文件所占用的空間要比其他文件本身大的多，此外，被刪除且在有效期內的文件都放在 一個“垃圾箱”中，所以他們也占用的空間，其大小也依賴文件的分鍾。。為防止刪除被其他進程打開的文件，數據將一直被存儲，直到文件被關閉。 被刪文件的文件名在“垃圾箱”目錄里還可見,文件名由一個八位十六進制的數i-node 和被刪文件的文件名組成，在文件名和i-node 之間不是用“/”,而是用了“|”替代。 如果一個文件名的長度超過操作系統的限制（通常是255 個字符），那么部分將被刪除。通過從掛載點起全路徑的文件名被刪除的文件仍然可以被讀寫。 移動這個文件到trash/undel 子目錄下，將會使原始的文件恢復到正確的MooseFS 文件系統上路徑下（如果路徑沒有改變）。如果在同一路徑下有個新的同名文件， 那么恢復不會成功。從“垃圾箱”中刪除文件結果是釋放之前被它站用的空間(刪除有延遲,數據被異步刪除)。 刪除的文件通過一個單獨安裝的mfsmeta輔助文件系統來恢復。這個文件系統包含了目錄trash（含有仍然可以被還原的刪除文件的信息）和目錄trash/undel（用於獲取文件）。 只有管理員權限訪問mfsmeta輔助文件系統(通常是root) ---------------------------下面測試下MFS回收站功能------------------------------ 在mfs掛載點刪除一個文件，在mfsmeta掛載點可以找到: [root@clinet-server ~]# echo "asdfasdfnoijoiujro2er0" >/mnt/mfs/haha1 [root@clinet-server ~]# /usr/local/mfs/bin/mfsrgettrashtime /mnt/mfs/haha1 deprecated tool - use "mfsgettrashtime -r" /mnt/mfs/haha1: files with trashtime 14400 : 1 //確認回收站存放的時間為4小時 [root@clinet-server ~]# rm /mnt/mfs/haha1 //刪除文件 rm: remove regular file `/mnt/mfs/haha1'? y [root@clinet-server ~]# find /mnt/mfsmeta/trash/ -name "*haha*" //在回收站里面找到被刪除的文件 /mnt/mfsmeta/trash/01F/0000001F|haha1 被刪除的文件名在垃圾箱里面其實還是可以找到的，文件名是由一個8位16進制數的i-node和被刪的文件名組成。在文件名和i-node之間不可以用"/"，而是以"|"替代。 如果一個文件名的長度超過操作系統的限制（通常是255字符），那么超出部分將被刪除。從掛載點起全部路徑的文件名被刪除的文件仍然可以被讀寫。 需要注意的是，被刪除的文件在使用文件名（注意文件名是兩部分），一定要用單引號引起來。如下所示： [root@clinet-server ~]# cat '/mnt/mfsmeta/trash/01F/0000001F|haha1' haha1 從回收站里恢復已刪除的文件 移動這個文件到文件所在目錄下的undel下面，將會使原始的文件恢復到正確的MFS文件系統原來的路徑下。如下所示： [root@clinet-server ~]# cd /mnt/mfsmeta/trash/01F [root@clinet-server 01F]# ls 0000001F|haha1 undel [root@clinet-server 01F]# mv 0000001F\|haha1 ./undel/ [root@clinet-server 01F]# cat /mnt/mfs/haha1 //發現haha1文件已經恢復了 asdfasdfnoijoiujro2er0 在恢復文件的時候，原來被刪文件下面的目錄下，不能有同名文件，不然恢復不成功。 從垃圾箱中刪除文件的結構是釋放之前它占用的空間（刪除有延遲，因為數據是異步刪除的）。在垃圾箱中刪除文件后，就不能夠再恢復了。 可以通過mfssetgoal命令來修改文件的副本數，也可以通過mfssettrashtime工具來改變文件存儲在垃圾箱中的時間。 ----------------------------為垃圾箱設定隔離時間--------------------------------------- 刪除的文件存放在"垃圾箱（trash bin）"的時間就是隔離時間（quarantine time）,即一個刪除文件能夠存放在一個"垃圾箱"的時間。 這個時間可以用mfsrgettrashtime命令來驗證，也可以用mfssettrashtime或者mfsrsettrashtime命令來設置。 設置的時間是按照小時計算，設置的單位是秒，不滿一小時就按一小時計算，如下所示： [root@clinet-server ~]# /usr/local/mfs/bin/mfssettrashtime 600 /mnt/mfs/ /mnt/mfs/: 600 上面設置為600秒，即10分鍾，不足1小時，算作1小時，所以查看結果是3600秒（即1小時） [root@clinet-server ~]# /usr/local/mfs/bin/mfsrgettrashtime /mnt/mfs deprecated tool - use "mfsgettrashtime -r" /mnt/mfs: files with trashtime 3600 : 2 directories with trashtime 3600 : 1 #查看這一行結果 [root@clinet-server ~]# /usr/local/mfs/bin/mfssettrashtime 6000 /mnt/mfs/ /mnt/mfs/: 6000 設置6000秒，多余1小時，不足2小時，結果算作是2小時 [root@clinet-server ~]# /usr/local/mfs/bin/mfsrgettrashtime /mnt/mfs deprecated tool - use "mfsgettrashtime -r" /mnt/mfs: files with trashtime 3600 : 2 directories with trashtime 7200 : 1 若把時間設置為0，說明文件執行刪除命令后，就會立即刪除，不可能再恢復，不進入回收站： [root@clinet-server ~]# /usr/local/mfs/bin/mfssettrashtime 0 /mnt/mfs/ /mnt/mfs/: 0 [root@clinet-server ~]# /usr/local/mfs/bin/mfsrgettrashtime /mnt/mfs deprecated tool - use "mfsgettrashtime -r" /mnt/mfs: files with trashtime 3600 : 2 directories with trashtime 0 : 1 mfssettrashtime -r是對目錄進行遞歸賦值的。為一個目錄設定存放時間后，在此目錄下新創建的文件和目錄就可以繼承這個設置了。 [root@clinet-server ~]# /usr/local/mfs/bin/mfssettrashtime -r 6000 /mnt/mfs/ /mnt/mfs/: inodes with trashtime changed: 4 inodes with trashtime not changed: 0 inodes with permission denied: 0 [root@clinet-server ~]# /usr/local/mfs/bin/mfsrgettrashtime /mnt/mfs/ deprecated tool - use "mfsgettrashtime -r" /mnt/mfs/: files with trashtime 7200 : 3 directories with trashtime 7200 : 1 [root@clinet-server ~]# /usr/local/mfs/bin/mfsrgettrashtime /mnt/mfs/haha1 deprecated tool - use "mfsgettrashtime -r" /mnt/mfs/haha1: files with trashtime 7200 : 1
2->設定目標的拷貝份數
目標（goal），是指文件被拷貝的份數，設定了拷貝的份數后是可以通過mfsgetgoal 命令來證實的，也可以通過mfsrsetgoal 來改變設定。
設置mfs文件系統中文件的副本個數，比如本案例中，設置2份：
[root@clinet-server ~]# /usr/local/mfs/bin/mfssetgoal 2 /mnt/mfs/test.txt
/mnt/mfs/test.txt: goal: 2
查看文件份數：
[root@clinet-server ~]# /usr/local/mfs/bin/mfsgetgoal /mnt/mfs/test.txt
/mnt/mfs/test.txt: 2
可以看出，與設置的文件副本數一致！
根據測試：goal number<=chunkserver number
即拷貝份數要不能多余chunkserver的節點數量
目錄設置與文件設置操作一致，給目錄設置goal，之后在該目錄下創建的文件將會繼承該goal，但不會影響到已經存在的文件。
[root@clinet-server ~]# /usr/local/mfs/bin/mfssetgoal 2 /mnt/mfs
/mnt/mfs: goal: 2
[root@clinet-server ~]# /usr/local/mfs/bin/mfsgetgoal /mnt/mfs
/mnt/mfs: 2
若要使該命令遞歸到目錄下的所有文件，添加-r參數。
用mfsgetgoal –r 和mfssetgoal –r 同樣的操作可以對整個樹形目錄遞歸操作，其等效於mfsrsetgoal命令
[root@clinet-server ~]# /usr/local/mfs/bin/mfssetgoal -r 2 /mnt/mfs
/mnt/mfs:
inodes with goal changed: 0
inodes with goal not changed: 2
inodes with permission denied: 0
[root@clinet-server ~]# /usr/local/mfs/bin/mfsgetgoal -r /mnt/mfs
/mnt/mfs:
files with goal 2 : 2
directories with goal 2 : 1
[root@clinet-server ~]# /usr/local/mfs/bin/mfsrgetgoal /mnt/mfs
deprecated tool - use "mfsgetgoal -r"
/mnt/mfs:
files with goal 2 : 2
directories with goal 2 : 1
----------------------------------------------------------------------------------------------------------------------------------------
對一個目錄設定“goal”，此目錄下的新創建文件和子目錄均會繼承此目錄的設定，但不會改變已經存在的文件及目錄的copy份數。但使用-r選項可以更改已經存在的copy份數。
goal設置為2，只要兩個chunkserver有一個能夠正常運行，數據就能保證完整性。
假如每個文件的goal（保存份數）都不小於2，並且沒有under-goal文件（可以用mfsgetgoal –r和mfsdirinfo命令來檢查），那么一個單一的chunkserver在任何時刻都可能做
停止或者是重新啟動。以后每當需要做停止或者是重新啟動另一個chunkserver的時候，要確定之前的chunkserver被連接，而且要沒有under-goal chunks。
實際測試時，傳輸一個大文件，設置存儲2份。傳輸過程中，關掉chunkserver1，這樣絕對會出現有部分塊只存在chunkserver2上；啟動chunkserver1，關閉chuner2，這樣絕對
會有部分塊只存在chuner1上。把chunkserver2啟動起來。整個過程中，客戶端一直能夠正常傳輸。在客戶端查看，一段時間內，無法查看；稍后一段時間后，就可以訪問了。
文件正常，使用mfsfileinfo 查看此文件，發現有的塊分布在chunkserver1上，有的塊分布在chuner2上。使用mfssetgoal 2和mfssetgoal -r 2均不能改變此文件的目前塊的現狀。
但使用mfssetgoal -r 1后，所有塊都修改成1塊了，再mfssetgoal -r 2，所有塊都修改成2份了。
測試chunkserver端，直接斷電情況下，chunkserver會不會出問題：
1）數據傳輸過程中，關掉chunkserver1，等待數據傳輸完畢后，開機啟動chunkserver1.
chunkserver1啟動后，會自動從chunkserver2復制數據塊。整個過程中文件訪問不受影響。
2）數據傳輸過程中，關掉chunkserver1，不等待數據傳輸完畢，開機啟動chunkserver1.
chunkserver1啟動后，client端會向chunkserver1傳輸數據，同時chunkserver1也從chunkserver2復制缺失的塊。
如果有三台chunkserver，設置goal=2，則隨機挑選2個chunkserver存儲。
如果有一個chunkserver不能提供服務，則剩余的2個chunkserver上肯定有部分chunks（塊）保存的是一份。則在參數（REPLICATIONS_DELAY_DISCONNECT = 3600）后，只有一份的chunks
會自動復制一份，即保存兩份。保存兩份后，如果此時壞掉的chunkserver能夠提供服務后，此時肯定有部分chunks存儲了三份，mfs會自動刪除一份。
當增加第三個服務器做為額外的chunkserver時，雖然goal設置為2，但看起來第三個chunkserver從另外兩個chunkserver上復制數據。
是的，硬盤空間平衡器是獨立地使用chunks的，因此一個文件的chunks會被重新分配到所有的chunkserver上。
----------------------------------------------------------------------------------------------------------------------------------------------
查看文件的實際副本數量可以通過mfscheckfile和mfsfileinfo命令證實。
mfscheckfile可查看copy數：
mfsfileinfo可查看具體的copy位置
注意下面幾個特殊情況：
1）一個不包含數據的零長度的文件,盡管沒有設置為非零的目標，但用mfscheckfile命令查詢將返回一個空的結果；將文件填充內容后，其會根據設置的goal創建副本；
這時再將文件清空，其副本依然作為空文件存在。
2）假如改變一個已經存在的文件的拷貝個數，那么文件的拷貝份數將會被擴大或者被刪除，這個過程會有延時。可以通過mfscheckfile 命令來證實。
3）對一個目錄設定“目標”，此目錄下的新創建文件和子目錄均會繼承此目錄的設定，但不會改變已經存在的文件及目錄的拷貝份數。可以通過mfsdirinfo來查看整個目錄樹的信息摘要。
如下示例：
[root@clinet-server ~]# touch /mnt/mfs/wangshibo
[root@clinet-server ~]# /usr/local/mfs/bin/mfscheckfile /mnt/mfs/wangshibo
/mnt/mfs/wangshibo: //雖然有文件（雖然沒有設置為非零目標，the noo-zero goal），但是是一個空文件，所以mfscheckfile是為空的結果。
[root@clinet-server ~]# /usr/local/mfs/bin/mfsfileinfo /mnt/mfs/wangshibo
/mnt/mfs/wangshibo:
no chunks - empty file
往上面測試文件里寫入數據
[root@clinet-server ~]# echo "1213442134" > /mnt/mfs/wangshibo
[root@clinet-server ~]# echo "1213442134" > /mnt/mfs/wangshibo
[root@clinet-server ~]# /usr/local/mfs/bin/mfscheckfile /mnt/mfs/wangshibo
/mnt/mfs/wangshibo:
chunks with 2 copies: 1
[root@clinet-server ~]# /usr/local/mfs/bin/mfsfileinfo /mnt/mfs/wangshibo
/mnt/mfs/wangshibo:
chunk 0: 0000000000000015_00000001 / (id:21 ver:1)
copy 1: 182.48.115.236:9422 (status:VALID)
copy 2: 182.48.115.237:9422 (status:VALID) //由於上面對/mnt/mfs目錄進行遞歸設置拷貝的份數是2，所以這里顯示的副本數正好是2
下面設置/mnt/mfs/wangshibo 文件的副本數為3或者大於3的副本數
[root@clinet-server ~]# /usr/local/mfs/bin/mfssetgoal 3 /mnt/mfs/wangshibo
/mnt/mfs/wangshibo: goal: 3
[root@clinet-server ~]# /usr/local/mfs/bin/mfsgetgoal /mnt/mfs/wangshibo
/mnt/mfs/wangshibo: 3
[root@clinet-server ~]# echo "asdfasdfasdf" > /mnt/mfs/wangshibo
[root@clinet-server ~]# /usr/local/mfs/bin/mfscheckfile /mnt/mfs/wangshibo
/mnt/mfs/wangshibo:
chunks with 2 copies: 1
[root@clinet-server ~]# /usr/local/mfs/bin/mfsfileinfo /mnt/mfs/wangshibo
/mnt/mfs/wangshibo:
chunk 0: 0000000000000017_00000001 / (id:23 ver:1)
copy 1: 182.48.115.236:9422 (status:VALID)
copy 2: 182.48.115.237:9422 (status:VALID)
以上可知，雖然將文件的副本數設置為3（或者大於3），理論上應該是復制3份副本，但是這里的chunkserver只有2台，所以copy也就為2了。
因此得出結論，goal number不能超過chunkserver number，要小於或等於chunkserver的數量。
另外，需要特別注意的是：
如果你的Chunkserver只有n台服務器，那么goal拷貝份數就設置為n即可，千萬別設置為超過n的數目，不然往文件里寫入數據時，會很卡！！
順便說說目錄繼承副本數量的問題：
1）如果改變一個已經存在的文件副本份數，那么文件的副本份數就會擴大或刪除，這個過程會有延遲的。
2）對於一個目錄設定"目標"，此目錄下新創建的文件或子目錄均會繼承此目錄的設定，但不會改變已經存在的文件以及目錄副本數量。
--------------------------------------------------------------------------------------------------------------------------------
mfsdirinfo
整個目錄樹的內容需要通過一個功能增強、等同於“du -s”的命令mfsdirinfo來顯示。mfsdirinfo可以顯示MFS的具體信息，查看目錄樹的內容摘要：
[root@clinet-server ~]# /usr/local/mfs/bin/mfsdirinfo /mnt/mfs
/mnt/mfs:
inodes: 5
directories: 1
files: 4
chunks: 4
length: 12342
size: 294912
realsize: 1253376
其中：
1）length 表示文件大小的總和
2）size 表示塊長度總和
3）realsize 表示磁盤空間的使用，包括所有的副本
3->快照功能
MFS系統可以利用mfsmakesnapshot工具給文件或者目錄做快照（snapshot），如下所示，將mfs文件體系下的wangshibo文件做快照
[root@clinet-server ~]# cd /mnt/mfs
[root@clinet-server mfs]# ls
wangshibo
[root@clinet-server mfs]# /usr/local/mfs/bin/mfsmakesnapshot wangshibo /opt/wangshibo-snapshot
(/opt/wangshibo-snapshot,wangshibo): both elements must be on the same device
[root@clinet-server mfs]# /usr/local/mfs/bin/mfsmakesnapshot wangshibo wangshibo-snapshot
[root@clinet-server mfs]# ll
total 1
-rw-r--r--. 1 root root 12 May 23 10:38 wangshibo
-rw-r--r--. 1 root root 12 May 23 10:38 wangshibo-snapshot
特別要注意的是：
不能將快照放到MFS文件系統之外的其他文件系統下，快照文件和源文件必須要在同一個MFS文件系統下（即路徑一致）
[root@clinet-server mfs]# /usr/local/mfs/bin/mfsfileinfo wangshibo-snapshot
wangshibo-snapshot:
chunk 0: 000000000000001A_00000001 / (id:26 ver:1)
copy 1: 182.48.115.236:9422 (status:VALID)
copy 2: 182.48.115.237:9422 (status:VALID)
[root@clinet-server mfs]# /usr/local/mfs/bin/mfsfileinfo wangshibo
wangshibo:
chunk 0: 000000000000001A_00000001 / (id:26 ver:1)
copy 1: 182.48.115.236:9422 (status:VALID)
copy 2: 182.48.115.237:9422 (status:VALID)
通過mfsfileinfo命令可以查看創建出來的文件快照，它只占用了一個inode，並不占用磁盤空間，就像ln命令創建硬鏈接類似！！！！
mfsmakesnapshot是一次執行中整合了一個或者一組文件的副本，而且對這些文件的源文件進行任何修改都不會影響源文件的快照，就是說任何對源文件的操作，如寫入操作，將會不修改副本。
mfsmakesnapshot可以實現這個快照功能，當有多個源文件時，他們的快照會被加入到同一個目標文件中，通過對比快照的測試，可以發現快照的本質：
1）一個MFS系統下的文件做快照后，查看兩個文件的塊信息，他們是同一個塊。接着，把原文件刪除，刪除源文件后（最初會留在回收站上，但過一段時間后回收站的文件也刪除了），快照
文件仍然存儲，並且可以訪問。使用mfsfileinfo查看，發現還是原來的塊。
2）對一個文件做快照后，查看兩個文件的塊信息，發現是同一個塊。把原文件修改后，發現原文件的使用塊信息變了，即使用了一個新塊。而快照文件仍然使用原來的塊，保持文件內容不變。
4->MFS掛載目錄技巧
1）掛載目錄管理 Moosefs系統支持客戶端根據需要掛載對應子目錄；默認不指定-S的話會掛載到根目錄（/）下，當通過df –sh查看空間使用used顯示的是當前整個mfs系統的硬盤使用情況； 而掛載子目錄則只會看到目錄的使用情況。具體操作如下： # mfsmount /mnt –H mfsmaster //掛載到MFS的根目錄（/）下。即在客戶端/mnt目錄下寫入的數據會直接寫到MFS的根目錄下。這里客戶端的掛載路徑可以自定義。 # mkdir –p /mnt/subdir # mfsmount /mnt –H mfsmaster –S /subdir //掛載到MFS子目錄（/subdir）下。這個subdir目錄是在MFS文件系統下真實存在的。在客戶端顯示的還是/mnt路徑，往里面寫入的數據其實是寫到了MFS的/mnt/subdir路徑下 在Moosefs的管理中，可以找一台機器作為管理型的client端，在master管理節點的配置文件mfsexports.cfg中限制只有該台機器可以掛載到根目錄下，同時也可限制只有 該台機器可以掛載metadata目錄（恢復誤刪除時可用到），而其他普通client端，則根據不同業務的需要讓管理client端為其創建獨立用途的目錄，分別掛載到對應的子 目錄下，這樣就可以細化管理控制權限。 在master管理節點的mfsexports.cfg的配置如下： [root@master-server mfs]# pwd /usr/local/mfs/etc/mfs [root@master-server mfs]# vim mfsexports.cfg ....... 182.48.115.238 / rw,alldirs,maproot=0 182.48.115.238 . rw //即允許182.48.115.238客戶機掛載MFS的根目錄 # for huanqiu data 182.48.115.239 /huanqiu rw.maproot=0 //即允許182.48.115.239客戶機掛載MFS的子目錄huanqiu（這個子目錄是真實存在MFS文件系統下的），在客戶端寫入的數據就會保存到MFS的子目錄huanqiu下 # for hatime data 182.48.115.240 /hqsb/hqtime rw.maproot=0 //即允許182.48.115.240客戶機掛載MFS的根目錄hqsb/hqtime（這個子目錄是真實存在MFS文件系統下的） ----------------------------------------------------------------------------------------------------------------------- 在客戶機182.48.115.238上掛載MFS文件系統的根目錄，命令如下（掛載后，df -h或mount命令都能查看到掛載信息） [root@clinet-238 ~]# /usr/local/mfs/bin/mfsmount /mnt/mfs -H 182.48.115.233 這樣在182.48.115.238機器的掛載目錄/mnt/mfs里的數據就是MFS文件系統根目錄下的數據。這個掛載目錄在客戶機上可以隨意定義。在/mnt/mfs掛載目錄下寫入數據，就會自動同步到MFS文件系統的根目錄下 [root@clinet-238 ~]# cd /mnt/mfs [root@clinet-238 mfs]# ll total 3 drwxr-xr-x. 3 root root 0 May 23 12:57 hqsb drwxr-xr-x. 2 root root 1800 May 23 13:04 huanqiu -rw-r--r--. 1 root root 39 May 23 12:54 ip_list ----------------------------------------------------------------------------------------------------------------------- 在客戶機182.48.115.239上掛載MFS文件系統的子目錄huanqiu [root@clinet-239]# mkdir -p /opt/huanqiu [root@clinet-239]# /usr/local/mfs/bin/mfsmount /opt/huanqiu -H 182.48.115.233 -S huanqiu //后面的子目錄寫成"huanqiu"或"/huanqiu"都可以 [root@clinet-239]# cd /opt/huanqiu/ [root@clinet-239]# echo "huanqiu test data" > hq.txt //寫入數據，則會自動同步到MFS文件系統的子目錄huanqiu下 到掛載MFS根目錄的182.48.115.238客戶機上查看，發現MFS的子目錄huanqiu下已經有了新數據 [root@clinet-238 ~]# cd /mnt/mfs [root@clinet-238 mfs]# ll total 3 drwxr-xr-x. 3 root root 0 May 23 12:57 hqsb drwxr-xr-x. 2 root root 1800 May 23 13:04 huanqiu -rw-r--r--. 1 root root 39 May 23 12:54 ip_list [root@clinet-238 mfs]# cd huanqiu/ [root@clinet-238 huanqiu]# ll total 1 -rw-r--r--. 1 root root 18 May 23 13:04 hq.txt [root@clinet-238 huanqiu]# cat hq.txt huanqiu test data ----------------------------------------------------------------------------------------------------------------------- 在客戶機182.48.115.240上掛載MFS文件系統的子目錄hqsb/hqtime [root@clinet-240 ~]# mkdir -p /mfs/data [root@clinet-240 ~]# /usr/local/mfs/bin/mfsmount /mfs/data -H 182.48.115.233 -S /hqsb/hqtime //將MFS文件系統的子目錄hqsb/hqtime掛載到本機的/mfs/data下 [root@clinet-240 ~]# cd /mfs/data/ [root@clinet-240 data]# echo "hatime 12313123123" > test 到掛載MFS根目錄的182.48.115.238客戶機上查看，發現MFS的子目錄hqsb/hqtime下已經有了新數據 [root@clinet-238 ~]# cd /mnt/mfs/hqsb/hqtime/ [root@clinet-238 hqtime]# ls test [root@clinet-238 hqtime]# cat test hatime 12313123123 2）客戶端重啟后自動掛載mfs目錄 # vim /etc/rc.local ...... /sbin/modprobe fuse /usr/bin/mfsmount /mnt1 -H mfsmaster -S /backup/db /usr/bin/mfsmount /mnt2 -H mfsmaster -S /app/image Moosefs官方網頁上有提到，1.6.x以上的版本還可以通過/etc/fstab的方式，系統重啟后自動掛載mfs文件系統，測試之后，並沒有成功，原因是FUSE模塊沒有加載到內核。 所以，用/etc/fstab，FUSE模塊需要事先將其編譯進系統內核中才行。fstab的配置如下： # vim /etc/fstab mfsmount /mnt fuse mfsmaster=MASTER_IP,mfsport=9421,_netdev 0 0 //重啟系統后掛載MFS的根目錄 mfsmount /mnt fuse mfstermaster=MASTER_IP,mfsport=9421,mfssubfolder=/subdir,_netdev 0 0 //重啟系統后掛載MFS的子目錄 采用fstab配置文件掛載方式可以通過如下命令，測試是否配置正確： # mount –a –t fuse 3）Moosefs可以節省空間 通過測試發現，拷貝到mfs目錄下的文件大小比ext3下的小了很多，開始以為是少同步了一些文件，於是又將mfs下的所有文件拷回到ext3下，發現大小和之前的一致。 所以說，mfs對小文件（測試文件為8K左右）存儲空間的節省非常明顯，可以節省一半的空間。 對於大文件存儲，mfs同樣可以節省空間。拷貝了一個1.7G文件到mfs下，大小為1.6G。
5->MFS元數據損壞后的恢復（簡單解決Master單點故障的瓶頸）
當master管理節點（即元數據服務器）出現故障導致元數據損壞后，可以通過Metalogger元數據日志服務器上的備份數據進行恢復！ 通常元數據有兩部分的數據： 1）主要元數據文件metadata.mfs，當mfsmaster運行的時候會被命名為metadata.mfs.back 2）元數據改變日志changelog.*.mfs，存儲了過去的N小時的文件改變。主要的元數據文件需要定期備份，備份的頻率取決於取決於多少小時changelogs儲存。 元數據changelogs應該實時的自動復制。自從MooseFS 1.6.5,這兩項任務是由mfsmetalogger守護進程做的。 元數據損壞是指由於各種原因導致master上的metadata.mfs數據文件不可用。一旦元數據損壞，所有的存儲在moosefs上的文件都不可使用。 一旦master管理節點出現崩潰（比如因為主機或電源失敗），需要最后一個元數據日志changelog並入主要的metadata中。 這個操作時通過mfsmetarestore工具做的，最簡單的方法是： # /usr/local/mfs/sbin/mfsmetarestore -a 如果master數據被存儲在MooseFS編譯指定地點外的路徑，則要利用-d參數指定使用，比如： # /usr/local/mfs/sbin/mfsmetarestore -a -d /storage/mfsmaster ------------------------------------------------------------------------------------------------------------------------- 下面模擬一個元數據損壞后的恢復操作 停止master節點並刪除metadata.mfs及changelog.0.mfs（變更日志文件）。 [root@master-server ~]# /etc/init.d/mfsmaster stop //master服務關閉后，在客戶端的現象是：掛載目錄下操作一直在卡的狀態中 [root@master-server ~]# cd /usr/local/mfs/var/mfs [root@master-server mfs]# ls changelog.11.mfs changelog.21.mfs changelog.24.mfs changelog.28.mfs changelog.34.mfs changelog.5.mfs metadata.mfs.empty changelog.19.mfs changelog.22.mfs changelog.25.mfs changelog.29.mfs changelog.3.mfs metadata.mfs mfsmaster changelog.1.mfs changelog.23.mfs changelog.27.mfs changelog.2.mfs changelog.4.mfs metadata.mfs.back.1 stats.mfs [root@master-server mfs]# rm -rf ./* 然后重新啟動master將報錯： [root@master-server mfs]# /etc/init.d/mfsmaster start open files limit has been set to: 16384 working directory: /usr/local/mfs/var/mfs lockfile created and locked initializing mfsmaster modules ... exports file has been loaded topology file has been loaded loading metadata ... can't find metadata.mfs - try using option '-a' init: metadata manager failed !!! error occurred during initialization - exiting ---------------------------------------現在進行元數據恢復--------------------------------- 從metalogger元數據日志服務器上將最新一份metadata_ml.mfs.back及changelog_ml.0.mfs復制到master元數據服務器的的數據目錄下，並注意文件屬主屬組為mfs。 （或者可以拷貝全部數據到Master元數據服務器上，這個沒驗證） 先登陸metalogger元數據日志服務器上查看 [root@metalogger ~]# cd /usr/local/mfs/var/mfs total 108 -rw-r-----. 1 mfs mfs 2186 May 23 13:27 changelog_ml.0.mfs -rw-r-----. 1 mfs mfs 26 May 23 03:46 changelog_ml.10.mfs -rw-r-----. 1 mfs mfs 400 May 22 19:11 changelog_ml.18.mfs -rw-r-----. 1 mfs mfs 1376 May 23 12:57 changelog_ml.1.mfs -rw-r-----. 1 mfs mfs 1313 May 22 17:41 changelog_ml.20.mfs -rw-r-----. 1 mfs mfs 9848 May 22 16:58 changelog_ml.21.mfs -rw-r-----. 1 mfs mfs 18979 May 22 15:57 changelog_ml.22.mfs -rw-r-----. 1 mfs mfs 1758 May 22 14:58 changelog_ml.23.mfs -rw-r-----. 1 mfs mfs 2388 May 23 11:29 changelog_ml.2.mfs -rw-r-----. 1 mfs mfs 3780 May 23 10:59 changelog_ml.3.mfs -rw-r-----. 1 mfs mfs 1886 May 23 09:56 changelog_ml.4.mfs -rw-r-----. 1 mfs mfs 558 May 23 13:10 changelog_ml_back.0.mfs -rw-r-----. 1 mfs mfs 1376 May 23 13:10 changelog_ml_back.1.mfs -rw-r--r--. 1 mfs mfs 8 May 22 14:16 metadata.mfs -rw-r-----. 1 mfs mfs 4783 May 23 13:10 metadata_ml.mfs.back -rw-r-----. 1 mfs mfs 4594 May 23 12:10 metadata_ml.mfs.back.1 -rw-r-----. 1 mfs mfs 4834 May 23 11:10 metadata_ml.mfs.back.2 -rw-r-----. 1 mfs mfs 4028 May 23 10:10 metadata_ml.mfs.back.3 [root@metalogger mfs]# rsync -e "ssh -p22" -avpgolr metadata_ml.mfs.back changelog_ml.0.mfs 182.48.115.233:/usr/local/mfs/var/mfs/ 然后在master元數據服務器上修改復制過來的文件屬性 [root@master-server mfs]# chown -R mfs.mfs ./* [root@master-server mfs]# ll total 12 -rw-r-----. 1 mfs mfs 27 May 23 14:40 changelog.0.mfs -rw-r-----. 1 mfs mfs 2213 May 23 14:34 changelog_ml.0.mfs 啟動master服務 [root@master-server mfs]# /etc/init.d/mfsmaster start open files limit has been set to: 16384 working directory: /usr/local/mfs/var/mfs lockfile created and locked initializing mfsmaster modules ... exports file has been loaded topology file has been loaded loading metadata ... can't find metadata.mfs - try using option '-a' init: metadata manager failed !!! error occurred during initialization - exiting 發現啟動還是報錯！！！ mfs的操作日志都記錄到changelog.0.mfs里面。changelog.0.mfs每小時合並一次到metadata.mfs中 此時應該利用mfsmetarestore命令合並元數據changelogs，可以用自動恢復模式命令"mfsmetarestore –a" [root@master-server mfs]# /usr/local/mfs/sbin/mfsmetarestore -a mfsmetarestore has been removed in version 1.7, use mfsmaster -a instead 然后需要以-a方式啟動master [root@master-server mfs]# /usr/local/mfs/sbin/mfsmaster -a open files limit has been set to: 16384 working directory: /usr/local/mfs/var/mfs lockfile created and locked initializing mfsmaster modules ... exports file has been loaded topology file has been loaded loading metadata ... loading sessions data ... ok (0.0000) loading storage classes data ... ok (0.0000) loading objects (files,directories,etc.) ... ok (0.1653) loading names ... ok (0.1587) loading deletion timestamps ... ok (0.0000) loading quota definitions ... ok (0.0000) loading xattr data ... ok (0.0000) loading posix_acl data ... ok (0.0000) loading open files data ... ok (0.0000) loading flock_locks data ... ok (0.0000) loading posix_locks data ... ok (0.0000) loading chunkservers data ... ok (0.0000) loading chunks data ... ok (0.1369) checking filesystem consistency ... ok connecting files and chunks ... ok all inodes: 17 directory inodes: 4 file inodes: 13 chunks: 10 metadata file has been loaded no charts data file - initializing empty charts master <-> metaloggers module: listen on *:9419 master <-> chunkservers module: listen on *:9420 main master server module: listen on *:9421 mfsmaster daemon initialized properly [root@master-server mfs]# ls changelog.0.mfs changelog_ml_back.1.mfs metadata_ml.mfs.back 此時，master服務已經啟動，元數據已經恢復了。 [root@master-server mfs]# ps -ef|grep mfs mfs 556 1 0 13:46 ? 00:00:26 /usr/local/mfs/sbin/mfsmaster -a root 580 24958 0 14:32 pts/0 00:00:00 grep mfs [root@master-server mfs]# lsof -i:9420 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME mfsmaster 556 mfs 9u IPv4 120727 0t0 TCP *:9420 (LISTEN) mfsmaster 556 mfs 11u IPv4 120737 0t0 TCP master-server:9420->chunkServer1:52513 (ESTABLISHED) mfsmaster 556 mfs 12u IPv4 120742 0t0 TCP master-server:9420->chunkServer2:45785 (ESTABLISHED) [root@master-server mfs]# ll total 12 -rw-r-----. 1 mfs mfs 27 May 23 14:40 changelog.0.mfs -rw-r-----. 1 mfs mfs 2213 May 23 14:34 changelog_ml.0.mfs -rw-r-----. 1 mfs mfs 3967 May 23 14:10 metadata_ml.mfs.back 可以在客戶端掛載mfs文件系統，查看元數據是否恢復及數據使用是否正常。
6->Moosefs存儲空間擴容
如上的部署環境：一台master、一台metalogger、兩台chunkserver（182.48.115.236和182.48.115.237）
在客戶端掛載MFS，並設置副本數為2。注意，副本數不能多余chunkserver的數量！
[root@clinet-server ~]# /usr/local/mfs/bin/mfsmount /mnt/mfs -H 182.48.115.233
mfsmaster accepted connection with parameters: read-write,restricted_ip,admin ; root mapped to root:root
[root@clinet-server ~]# /usr/local/mfs/bin/mfssetgoal -r 2 /mnt/mfs/
/mnt/mfs/:
inodes with goal changed: 19
inodes with goal not changed: 0
inodes with permission denied: 0
[root@clinet-server ~]# /usr/local/mfs/bin/mfsgetgoal /mnt/mfs
/mnt/mfs: 2
准備數據
[root@clinet-server mfs]# echo "asdfasdf" > /mnt/mfs/huihui
查看副本數情況
[root@clinet-server mfs]# /usr/local/mfs/bin/mfsfileinfo /mnt/mfs/huihui
/mnt/mfs/huihui:
chunk 0: 0000000000000031_00000001 / (id:49 ver:1)
copy 1: 182.48.115.236:9422 (status:VALID)
copy 2: 182.48.115.237422 (status:VALID)
如上，這個MFS文件系統下的huihui文件被切成了1個塊（chunks），做成了2個副本分別放在了182.48.115.236和182.48.115.237的chunkserver上了。
這兩個chunkserver只要有一個還在提供服務，則客戶端就能正常共享MFS下的這個文件數據。但如果兩個chunkserver都出現故障而不提供服務了，那
么客戶端就不能共享MFS下的這個文件了。
注意：
1）上面例子的文件太小，小文件的話，一般是只切割成了一個塊，如果文件比較大的話，就會切成很多歌chunks塊，比如chunk 0、chunk 1、chunk2、....
2）一旦副本數設定，並且副本已經存放到了分配的chunkserver上，后續再添加新的chunkserver，那么這些副本也不會再次放到這些新的chunkserver上了。
除非重新調整goal副本數，則chunks塊的副本會重新匹配chunkserver進行存放。
---------------------------------再看一個大文件的例子--------------------------------------------
上傳一個200多M的大文件到MFS文件系統里
[root@clinet-server ~]# cp -r install.img /mnt/mfs
[root@clinet-server ~]# du -sh /mnt/mfs/images/
270M /mnt/mfs/install.img
[root@clinet-server ~]# /usr/local/mfs/bin/mfsgetgoal /mnt/mfs/images/
/mnt/mfs/images/: 2
查看文件的副本數。如下發現這個大文件被切割成了4個chunks塊
[root@clinet-server mfs]# /usr/local/mfs/bin/mfsfileinfo /mnt/mfs/install.img
/mnt/mfs/install.img:
chunk 0: 0000000000000034_00000001 / (id:52 ver:1)
copy 1: 182.48.115.236:9422 (status:VALID)
copy 2: 182.48.115.237:9422 (status:VALID)
chunk 1: 0000000000000035_00000001 / (id:53 ver:1)
copy 1: 182.48.115.236:9422 (status:VALID)
copy 2: 182.48.115.237:9422 (status:VALID)
chunk 2: 0000000000000036_00000001 / (id:54 ver:1)
copy 1: 182.48.115.236:9422 (status:VALID)
copy 2: 182.48.115.237:9422 (status:VALID)
chunk 3: 000000000000003B_00000001 / (id:59 ver:1)
copy 1: 182.48.115.236:9422 (status:VALID)
copy 2: 182.48.115.237:9422 (status:VALID)
chunk 4: 000000000000003C_00000001 / (id:60 ver:1)
copy 1: 182.48.115.236:9422 (status:VALID)
copy 2: 182.48.115.237:9422 (status:VALID)
新增加兩台chunkserver節點（分別是103.10.86.20和103.10.86.22），擴容存儲空間.chunkserver安裝部署過程如上記錄。
如果goal副本數不修改，依然保持之前設定的2個副本，那么以上文件的4個chunks的各自副本數依然還會放到之前的2個chunkserver上，
不會調整到新增加的chunkserver上。
調整goal副本數
[root@clinet-server ~]# /usr/local/mfs/bin/mfssetgoal 3 /mnt/mfs/install.img
/mnt/mfs/install.img: goal: 3
[root@clinet-server ~]# /usr/local/mfs/bin/mfsgetgoal /mnt/mfs/install.img
/mnt/mfs/install.img: 3
再次查看副本數據，可以看到數據進行重新平衡
[root@clinet-server ~]# /usr/local/mfs/bin/mfsfileinfo /mnt/mfs/install.img
/mnt/mfs/install.img:
chunk 0: 0000000000000034_00000001 / (id:52 ver:1)
copy 1: 103.10.86.22:9422 (status:VALID)
copy 2: 182.48.115.236:9422 (status:VALID)
copy 3: 182.48.115.237:9422 (status:VALID)
chunk 1: 0000000000000035_00000001 / (id:53 ver:1)
copy 1: 103.10.86.22:9422 (status:VALID)
copy 2: 182.48.115.236:9422 (status:VALID)
copy 3: 182.48.115.237:9422 (status:VALID)
chunk 2: 0000000000000036_00000001 / (id:54 ver:1)
copy 1: 103.10.86.20:9422 (status:VALID)
copy 2: 182.48.115.236:9422 (status:VALID)
copy 3: 182.48.115.237:9422 (status:VALID)
chunk 3: 000000000000003B_00000001 / (id:59 ver:1)
copy 1: 103.10.86.22:9422 (status:VALID)
copy 2: 182.48.115.236:9422 (status:VALID)
copy 3: 182.48.115.237:9422 (status:VALID)
chunk 4: 000000000000003C_00000001 / (id:60 ver:1)
copy 1: 103.10.86.20:9422 (status:VALID)
copy 2: 182.48.115.236:9422 (status:VALID)
copy 3: 182.48.115.237:9422 (status:VALID)
上面是最終重新平衡后的效果（需要經過一定的分配過程），如果中間注意觀察，會發現chunks塊的各個副本的分配的過程。