分布式檔案系統（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塊的各個副本的配置設定的過程。 *************** 當你發現自己的才華撐不起野心時，就請安靜下來學習吧！***************