MFS近期測試故障點的總結：
1、 在mfs1.5.12的版本中，對大批量的文件傳輸進行了測試，經過反覆的測試測試對於大批量文件傳輸的情況，並跟進資源消耗的情況，但是測試的過程中出現了問題。
使用scp指令大批量的圖片時，在mfs客戶端忽然發現沒有了掛載的分區，重新掛載時出現：
[root@mysqldb log]# mfsmount -h 192.168.5.230 -w /usr/xxtsrc/pic/upload/
fuse: mountpoint is not empty
fuse: if you are sure this is safe, use the 'nonempty' mount option error in fuse_mount
但是查看mfs客戶端的進程是依然存在的。
（2）查看master上的/va/log/message日誌出現：
Jan 8 10:10:00 nginx mfsmaster[4845]: chunkservers status:
Jan 8 10:10:00 nginx mfsmaster[4845]: total: usedspace: 0 (0 GB), totalspace: 0 (0 GB), usage: 0.00%
這說明master沒有發現到chunker服務器。
（3）在chunker上日誌出現如下錯誤：
Jan 8 10:09:29 chunker1 mfschunkserver[16631]: chunk_before_io_int: file:/usr/xxtdata/5/chunk_000000000004B655_00000001.mfs - open
error (24:Too many open files)
Jan 8 10:09:29 chunker1 mfschunkserver[16631]: chunk_before_io_int: file:/usr/xxtdata/5/chunk_000000000004ADE5_00000002.mfs - open
error (24:Too many open files)
Jan 8 10:09:29 chunker1 mfschunkserver[16631]: create socket, error: Too many open files
Jan 8 10:09:43 chunker1 mfschunkserver[16631]: chunk_before_io_int: file:/usr/xxtdata/7/chunk_000000000004B047_00000002.mfs - open
error (24:Too many open files)
Jan 8 10:09:43 chunker1 mfschunkserver[16631]: chunk_before_io_int: file:/usr/xxtdata/D/chunk_000000000004B6BD_00000001.mfs - open
error (24:Too many open files)
Jan 8 10:09:44 chunker1 mfschunkserver[16631]: 3 errors occurred in 3600 seconds on folder: /usr/xxtdata/
根據提示調整了服務器的文件描述的限制，從1024加到最大，可是又發現如下問題：
Jan 8 10:35:14 chunker1 mfschunkserver[2713]: read_block_from_chunk: file:/usr/xxtdata/C/chunk_000000000004B6BC_00000002.mfs - crc
error
Jan 8 10:35:52 chunker1 mfschunkserver[2713]: read_block_from_chunk: file:/usr/xxtdata/B/chunk_000000000004B6BB_00000002.mfs - crc
error
Jan 8 10:36:31 chunker1 mfschunkserver[2713]: read_block_from_chunk: file:/usr/xxtdata/A/chunk_000000000004B6BA_00000002.mfs - crc
error
Jan 8 10:36:32 chunker1 mfschunkserver[2713]: 3 errors occurred in 3600 seconds on folder: /usr/xxtdata/
這說明有壞文件存在，致使校驗沒有通過，根據客戶端的提示：
Jan 8 10:38:54 nginx mfsmaster[4845]: * damaged file 308729: 2009/blog/gallery_photo_s/1231/01/2009021709270130.jpg
Jan 8 10:38:57 nginx mfsmaster[4845]: damaged chunk 308920 (file: 308810 ; index: 0)
Jan 8 10:38:57 nginx mfsmaster[4845]: * damaged file 308810: 2009/blog/gallery_photo_s/1231/01/2009101608332432.jpg
Jan 8 10:38:57 nginx mfsmaster[4845]: damaged chunk 308921 (file: 308811 ; index: 0)
Jan 8 10:38:57 nginx mfsmaster[4845]: * damaged file 308811: 2009/blog/gallery_photo_s/1231/01/2008051310541895.jpg
Jan 8 10:38:57 nginx mfsmaster[4845]: damaged chunk 308922 (file: 308812 ; index: 0)
Jan 8 10:38:57 nginx mfsmaster[4845]: * damaged file 308812: 2009/blog/gallery_photo_s/1231/01/2009022508435991.jpg
Jan 8 10:38:57 nginx mfsmaster[4845]: damaged chunk 308923 (file: 308813 ; index: 0)
Jan 8 10:38:57 nginx mfsmaster[4845]: * damaged file 308813: 2009/blog/gallery_photo_s/1231/01/2009021512192253.jpg
Jan 8 10:38:57 nginx mfsmaster[4845]: damaged chunk 308924 (file: 308814 ; index: 0)
Jan 8 10:38:57 nginx mfsmaster[4845]: * damaged file 308814: 2009/blog/gallery_photo_s/1231/01/2009070309000045.jpg
將上面的損壞文件刪除再次的重啓之後就恢復了正常。
針對上面的問題，和MFS的SA取得聯繫，他們說在開發mfs1.5.12的過程中遇到了此類的問題，並在1.6.x的版本中進行了改進，並完善了文件的修復機制，也是因此將測試從mfs1.5.12轉移到了mfs1.6.11中進行了測試。在後來的反覆測試中，對大批量文件傳輸反覆測試了20餘次沒有遇到類似的問題，而且在mfs1.6.x啓動的過程中也提示MFS也修改了相關的程序。
2、對於MFS1.6.x，分別就client、chunker、master的故障恢復、模擬停電、斷網、關機等環境，進行測試並就出現問題的解決辦法。
（1）MFS的client端:
斷電、斷網對MFS的體系不產生影響。
殺掉MFS的client服務會產生
df: `/usr/mfstest': Transport endpoint is not connected
處理的方式是umount /usr/mfstest，然後再重新掛載就可以了，這種 情況用戶MFS客戶端出現誤殺的情況。
（2）MFS的chunker端：
斷網、殺掉MFS的chunker程序對MFS系統無影響。
斷電：
#無文件傳輸時，對兩個chunker都無影響；
#當有文件傳輸時，但是文件設置存儲一份時，對文件的存儲無影響。
#當有文件傳輸，且設置文件存儲多份時：
★關掉chunker1之後，如果在chunker1恢復正常之前文件已經 傳輸完畢，那麼數據將從chunker2同步到chunker1中。
★關掉chunker1之後，如果在 chunker1恢復之後文件尚未傳 輸完畢，那麼文件將一方面繼續傳輸一方面從chunker2中進行 文件的同步。
★關掉chunker1之後隨即chunker2也掛掉的話就會影響MFS 的應用，因爲已經沒有了可用的chunker服務器了。
綜上可知，只要不是兩個chunker服務器同時掛掉的話，就不會 影響文件的傳輸，也不會影響服務的使用。
（3）MFS的master端：
斷網、殺掉MFS的master服務對MFS系統無影響。
斷電可能會出現以下的情況：
#當沒有文件傳輸時，可在服務器重啓之後，運行 /usr/local/mfs/sbin/mfsmetarestore –a進行修復，之後 /usr/local/mfs/sbin/mfsmaster start恢復master服務。
#當有文件傳輸時，可能會在/usr/local/mfs/sbin/mfsmetarestore –a進行修 復時可能會出現：
version after applying changelog: 1411141
applying changes from file: /usr/local/mfs/var/mfs/changelog.0.mfs
meta data version: 1411141
1411142: error: 13 (No such chunk)
但是使用metalogger進行修復出現：
version after applying changelog: 1410627
applying changes from file: /usr/local/mfs/var/mfs/changelog_ml.0.mfs
meta data version: 1410627
1411145: version mismatch
對於這個問題，測試的過程中對MFS的master主機進行反覆的斷電測試， 偶爾會出現這個情況，也向MFS的SA進行請教，但是一直未有回覆。
遇到上面的MFS遭遇停電的問題確實是比較頭痛的，無法修復無法啓動 master服務。但是我們就真的沒有辦法讓master起來麼？並不是的，我們可以直接將metadata.mfs.back複製成metadata.mfs ，然後再重啓master就可以了。但是這種方式會造成一個小時的數據丟失，而且下次遇到這樣的問題的時候也會出現無法修復的情況，還有就是有可能其他的不知道的問題。在等待一個小時後，在進行修復的話，這個問題就自然的解決了，但是也就是確定了我們將會丟失那些正在傳輸的數據，這也是這種修復方法的一個缺點吧。
