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就可以了。但是这种方式会造成一个小时的数据丢失，而且下次遇到这样的问题的时候也会出现无法修复的情况，还有就是有可能其他的不知道的问题。在等待一个小时后，在进行修复的话，这个问题就自然的解决了，但是也就是确定了我们将会丢失那些正在传输的数据，这也是这种修复方法的一个缺点吧。