3.3.2 配置：
$vi /usr/local/mfs/etc/mfsmetalogger.cfg
# WORKING_USER = mfs
# WORKING_GROUP = mfs
# SYSLOG_IDENT = mfsmetalogger
# LOCK_MEMORY = 0
# NICE_LEVEL = -19
# DATA_PATH = /usr/local/mfs/var/mfs
# BACK_LOGS = 50
# META_DOWNLOAD_FREQ = 24 元數據備份文件下載請求頻率。默認爲24小時，即每隔一天從元數據服務器(MASTER)下載一個metadata.mfs.back 文件。當元數據服務器關閉或者出故障時，matedata.mfs.back 文件將消失，那麼要恢復整個mfs,則需從metalogger 服務器取得該文件。請特別注意這個文件，它與日誌文件一起，才能夠恢復整個被損壞的分佈式文件系統。
# MASTER_RECONNECTION_DELAY = 5
MASTER_HOST = 192.168.0.1
# MASTER_PORT = 9419
# MASTER_TIMEOUT = 60
# deprecated, to be removed in MooseFS 1.7
# LOCK_FILE = /var/run/mfs/mfsmetalogger.lock
注意：
·MASTER_HOST 不能爲localhost或127.0.0.1，做單機測試的童鞋們注意了，要使用對外IP。
·MASTER_PORT必須爲元數據服務器配置中MATOCS_LISTEN_PORT指定的端口，且IP必須被master允許。
3.3.3 操作
/usr/local/mfs/sbin/mfsmetalogger [-vdu] [-t locktimeout] [-c cfgfile] [start|stop|restart|reload]#chunkserver操作命令
3.4 MFS Client
在192.168.0.6上執行如下操作：
3.4.1 FUSE安裝：
$wget http://nchc.dl.sourceforge.net/project/buluoos/0.2/src/fuse-2.8.5.tar.gz
$tar zxf fuse-2.8.5.tar.gz
$cd fuse-2.8.5
$./configure
$make && make install
$echo 'export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig:$PKG_CONFIG_PATH' >>/etc/profile
$source /etc/profile
$lsmod |grep fuse #檢查fuse是否加載到內核，若沒有，執行下面命令
$modprobe fuse&&lsmod |grep fuse#若將下列mfsmount掛載操作加入開機自啓動，一定將modprobe fuse也加入開機自啓
注意：
·一定要將fuse環境變量配置ok，否則安裝mfsmount會裝不上
·若將下列mfsmount掛載操作加入開機自啓動，一定將modprobe fuse也加入開機自啓，且在其執行之前執行。
3.4.2 MFSMount安裝：
$useradd mfs -s /sbin/nologin
$wget http://www.moosefs.org/tl_files/mfscode/mfs-1.6.20-2.tar.gz
$tar zxvf mfs-1.6.20-2.tar.gz
$cd mfs-1.6.20-2/
$./configure --prefix=/usr/local/mfs --with-default-user=mfs --with-default-group=mfs --disable-mfsmaster --disable-mfschunkserver
$make;make install
3.4.3 掛載MFS
$mkdir /mnt/mfs /mnt/mfsmeta#創建掛載點
$/usr/local/mfs/bin/mfsmount /mnt/mfs -H 192.168.0.1
$/usr/local/mfs/bin/mfsmount -m /mnt/mfsmeta -H 192.168.0.1
$df -h #檢查是否掛載成功
$umount /mnt/mfs #操作如下出錯，說明客戶端本機有正在使用此文件系統，可以查明是什麼命令正在使用，然後推出就可以了，最好不要強制退出。
到此爲止，我們的MFS集羣已經搭建完成。
四、MFS的高級特性
4.1 冗餘goal設置
目標（goal），是指文件被拷貝的份數，設定了拷貝的份數後是可以通過mfsgetgoal 命令來證實的，也可以通過mfsrsetgoal 來改變設定。
$/usr/local/mfs/bin/mfssetgoal 3 /mnt/mfs/test1
$/usr/local/mfs/bin/mfsgetgoal /mnt/mfs/test1
/mnt/mfs/test1: 3
用mfsgetgoal–r 和mfssetgoal–r 同樣的操作可以對整個樹形目錄遞歸操作，其等效於mfsrsetgoal命令。實際的拷貝份數可以通過mfscheckfile和mfsfile info 命令來證實。
注意以下幾種特殊情況：
·一個不包含數據的零長度的文件,儘管沒有設置爲非零的目標（the non-zero "goal"）,但用mfscheckfile 命令查詢將返回一個空的結果；將文件填充內容後，其會根據設置的goal創建副本；這時再將文件清空，其副本依然作爲空文件存在。
·假如改變一個已經存在的文件的拷貝個數，那麼文件的拷貝份數將會被擴大或者被刪除，這個過程會有延時。可以通過mfscheckfile 命令來證實。
·對一個目錄設定“目標”，此目錄下的新創建文件和子目錄均會繼承此目錄的設定，但不會改變已經存在的文件及目錄的拷貝份數。
可以通過mfsdirinfo來查看整個目錄樹的信息摘要。
4.2 垃圾回收站
一個刪除文件能夠存放在一個“ 垃圾箱”的時間就是一個隔離時間，這個時間可以用mfsgettrashtime命令來驗證，也可以用mfssettrashtime命令來設置。如：
$/usr/local/mfs/bin/mfssettrashtime 64800 /mnt/mfs/test1
$/usr/local/mfs/bin/mfsgettrashtime /mnt/mfs/test1
/mnt/mfs/test1: 64800
時間的單位是秒(有用的值有:1 小時是3600 秒,24 - 86400 秒,1天 - 604800 秒)。就像文件被存儲的份數一樣, 爲一個目錄設定存放時間是要被新創建的文件和目錄所繼承的。數字0 意味着一個文件被刪除後, 將立即被徹底刪除，在想回收是不可能的。
刪除文件可以通過一個單獨安裝MFSMETA 文件系統。特別是它包含目錄/ trash (包含任然可以被還原的被刪除文件的信息)和/ trash/undel (用於獲取文件)。只有管理員有權限訪問MFSMETA(用戶的uid 0，通常是root)。
$/usr/local/mfs/bin/mfsmount -m /mnt/mfsmeta -H 192.168.0.1
被刪文件的文件名在“垃圾箱”目錄裏還可見,文件名由一個八位十六進制的數i-node 和被刪文件的文件名組成，在文件名和i-node 之間不是用“/”,而是用了“|”替代。如果一個文件名的長度超過操作系統的限制（通常是255 個字符），那麼部分將被刪除。通過從掛載點起全路徑的文件名被刪除的文件任然可以被讀寫。
移動這個文件到trash/undel 子目錄下，將會使原始的文件恢復到正確的MooseFS 文件系統上路徑下（如果路徑沒有改變）。如果在同一路徑下有個新的同名文件，那麼恢復不會成功。
從“垃圾箱”中刪除文件結果是釋放之前被它站用的空間(刪除有延遲,數據被異步刪除)。
在MFSMETA中還有另一個目錄reserved，該目錄內的是被刪除但依然打開的文件。在用戶關閉了這些被打開的文件後，reserved 目錄中的文件將被刪除，文件的數據也將被立即刪除。在reserved 目錄中文件的命名方法同trash 目錄中的一樣，但是不能有其他功能的操作。
4.3 快照snapshot
MooseFS 系統的另一個特徵是利用mfsmakesnapshot工具給文件或者是目錄樹做快照。
$/usr/local/mfs/bin/mfsmakesnapshot source ... destination
Mfsmakesnapshot 是在一次執行中整合了一個或是一組文件的拷貝，而且任何修改這些文件的源文件都不會影響到源文件的快照，就是說任何對源文件的操作,例如寫入源文件，將不會修改副本(或反之亦然)。
也可以使用mfsappendchunks：
$/usr/local/mfs/bin/mfsappendchunks destination-file source-file ...
當有多個源文件時，它們的快照被加入到同一個目標文件中（每個chunk 的最大量是chunk）。
五、MFS的性能測試
下面是網上得到的一童鞋的簡單測試數據，直接拿過來了。
寫：time dd if=/dev/zero of=/mnt/mfs/test2/test500M bs=1024k count=500
讀：time dd if=/mnt/mfs/test2/test500M of=/dev/null
| | 1copy寫 | 2copy寫 | 1copy讀 | 2copy讀 |
1M | 0m0.042s | 0m0.042s | 0m0.017s | 0m0.017s |
5M | 0m0.073s | 0m0.079s | 0m0.070s | 0m0.071s |
20M | 0m0.250s | 0m0.288s | 0m0.291s | 0m0.376s |
50M | 0m0.514s | 0m0.589s | 0m0.896s | 0m0.886s |
100M | 0m0.977s | 0m7.497s | 0m1.677s | 0m1.787s |
200M | 0m7.910s | 0m22.270s | 0m2.683s | 0m3.129s |
500M | 0m22.465s | 0m51.735s | 0m6.559s | 0m6.990s |
1G | 0m52.346s | 1m48.056s | 0m17.319s | 0m17.154s |
2G | 1m46.224s | 3m46.283s | 0m41.608s | 0m34.435s |
10G | 9m29.037s | 19m26.237s | 3m55.222s | 3m24.914s |
·讀速度：ca 71M/s 寫速度：ca 22M/s 9M/s （以500M計算）
·goal的設置和讀寫速度的關係？貌似沒有太大關係。
另一份比較詳細的測試數據，就不粘出來了，直接把結果拿過來：
·單盤多進程性能沒有提升，因爲都在io wait，甚至增加進程會消耗大量調度時間
·MFS多進程時性能會提升，主要性能消耗集中在CPU系統時間。因此實際海量小文件性能要大大強於本地文件系統
六、MFS集羣的維護
6.1 啓動MFS集羣
最安全的啓動MooseFS 集羣（避免任何讀或寫的錯誤數據或類似的問題）的方式是按照以下命令步驟：
啓動mfsmaster 進程
啓動所有的mfschunkserver 進程
啓動mfsmetalogger 進程（如果配置了mfsmetalogger）
當所有的chunkservers 連接到MooseFS master 後，任何數目的客戶端可以利用mfsmount 去掛接被export 的文件系統。（可以通過檢查master 的日誌或是CGI 監視器來查看是否所有的chunkserver被連接）。
6.2 停止MFS集羣
安全的停止MooseFS 集羣：
在所有的客戶端卸載MooseFS 文件系統（用umount 命令或者是其它等效的命令）
用mfschunkserver stop 命令停止chunkserver 進程
用mfsmetalogger stop 命令停止metalogger 進程
用mfsmaster stop 命令停止master 進程
6.3 MFS chunkservers 的維護
若每個文件的goal（目標）都不小於2，並且沒有under-goal 文件（這些可以用mfsgetgoal –r和mfsdirinfo 命令來檢查），那麼一個單一的chunkserver 在任何時刻都可能做停止或者是重新啓動。以後每當需要做停止或者是重新啓動另一個chunkserver 的時候，要確定之前的chunkserver 被連接，而且要沒有under-goal chunks。
6.4 MFS元數據備份
通常元數據有兩部分的數據：
·主要元數據文件metadata.mfs，當mfsmaster 運行的時候會被命名爲metadata.mfs.back
·元數據改變日誌changelog.*.mfs，存儲了過去的N 小時的文件改變（N 的數值是由BACK_LOGS參數設置的，參數的設置在mfschunkserver.cfg 配置文件中）。
主要的元數據文件需要定期備份，備份的頻率取決於取決於多少小時changelogs 儲存。元數據changelogs 實時的自動複製。1.6版本中這個工作都由metalogger完成。
6.5 MFS Master的恢復
一旦mfsmaster 崩潰（例如因爲主機或電源失敗），需要最後一個元數據日誌changelog 併入主要的metadata 中。這個操作時通過mfsmetarestore工具做的，最簡單的方法是：
$/usr/local/mfs/bin/mfsmetarestore -a
如果master 數據被存儲在MooseFS 編譯指定地點外的路徑，則要利用-d 參數指定使用，如：
$/usr/local/mfs/bin/mfsmetarestore -a -d /opt/mfsmaster
6.6 從MetaLogger中恢復Master
有些童鞋提到：如果mfsmetarestore -a無法修復，則使用metalogger也可能無法修復，暫時沒遇到過這種情況，這裏不暫不考慮。
找回metadata.mfs.back 文件，可以從備份中找，也可以中metalogger 主機中找（如果啓動了metalogger 服務），然後把metadata.mfs.back 放入data 目錄，一般爲{prefix}/var/mfs
從在master 宕掉之前的任何運行metalogger 服務的服務器上拷貝最後metadata 文件，然後放入mfsmaster 的數據目錄。
利用mfsmetarestore 命令合併元數據changelogs，可以用自動恢復模式mfsmetarestore –a，也可以利用非自動化恢復模式
$mfsmetarestore -m metadata.mfs.back -o metadata.mfs changelog_ml.*.mfs
或：
強制使用metadata.mfs.back創建metadata.mfs，可以啓動master，但丟失的數據暫無法確定。
七、MFS的常見問題和建議對策
7.1 Master性能瓶頸
master本身的性能瓶頸。
短期對策：按業務切分
7.2 體系架構存儲文件總數的瓶頸
mfs把文件系統的結構緩存到master的內存中，個人認爲文件越多，master的內存消耗越大，8g對應2500kw的文件數，2億文件就得64GB內存。
短期對策：按業務切分
7.3 單點故障解決方案的健壯性
7.4 垃圾回收
默認的垃圾回收時間是86400，存在一種可能性是垃圾還沒回收完，你的存儲容量就暴掉了。
方案一：設置垃圾回收時間，積極監控存儲容量。
經過測試，把垃圾回收時間設置300秒，完全可以正確回收容量。
方案二：手動週期性去刪除metamfs裏的trash目錄下的文件（健壯性還有待測試，反正刪除後容量是回收了，不曉得有沒有什麼後遺症。）
7.5 理想的平均寫和讀的速度是多少？
原始的讀/寫速度很明顯是主要取決於所使用的硬盤的性能、網絡的容量和拓撲結構的，使用的硬盤和網絡的吞吐量越好，整個系統的性能也就會越好。官方的測試環境中，將MFS安裝在linux（Debian）上設置存儲的份數爲2，一般的測試服務器（還做了其他較大量的計算），G太網絡，使用Pbyte級別的數據，測試的結果爲寫的速度大約在20-30MB/s，讀的速度爲30-50MB/s。對於小文件寫的速度有些下降，但是對於讀的速度是沒有影響的。
7.6 設置文件存儲的份數是否影響寫/讀的速度？
一般來說，它是有影響的。在一定條件下，存儲份數的設置會影響的讀取的速度。例如，當文件設置存儲兩份而不是一份時能加快對同一文件有多個客戶端讀取的速度。但是在真實的環境中，多個機器同時讀取同一個文件的機率是比較小的，因此，存儲份數的設置對讀取的速度影響是比較小的。
同樣，設置存儲份數對寫的速度影響也是不太大的。(只有文件超過64M的時候)
本次總結主要來自一些網絡上的資料和當前生產環境使用MFS的一些經驗。
參考資料：《MFS知識大彙總》、《MFS權威指南》、《MFS文件系統使用手冊》