一、MFS介绍：
Distinctive features of MooseFS are:
- higher reliability (data can be stored in several copies on separate computers)
高可用性：数据可以在不同机器上存储多个副本
- dynamically expanding disk space by attaching new computers/disks
动态扩展：随时新增加机器或者是磁盘
- possibility of storing deleted files for a defined period of time ("trash
bin" service on a file system level)
回收站：可还原在回收站内的文件
- possibility of creating snapshot of a file, which means coherent copy of the
whole file, even while the file is being written.
快照：可以对整个文件甚至在正在写入的文件创建文件的快照
MFS文件系统结构: 包含4种角色:
管理服务器managing server (master) ：负责各个数据存储服务器的管理，文件读写调度，文件空间回收以及恢复.多节点拷贝。single computer managing the whole filesystem,storing metadata for every file (information on size, attributes and file localisation(s), including all information about non-regular files, i.e.directories, sockets, pipes and devices).
Master（单个机器）管理整个文件系统，用来存储记录每一个文件的Metadata（记录文件的大小、文件的属性、文件的位置，也包括非规则文件，如目录、sockets、管道和设备）
元数据日志服务器Metalogger server（Metalogger）：负责备份master服务器的变化日志文件，文件类型为changelog_ml.*.mfs，以便于在master server出问题的时候接替其进行工作。
数据存储服务器data servers (chunkservers) ：负责连接管理服务器,听从管理服务器调度，提供存储空间，并为客户提供数据传输。
客户机挂载使用client computers ：通过fuse内核接口挂接远程管理服务器上所管理的数据存储服务器,.看起来共享的文件系统和本地unix文件系统使用一样的效果。
二、mfs各元素主要配置文件
1、master
Metadata（元数据）存储在master服务器的内存中，同时也保存在磁盘上（作为一个定期更新的二进制文件，并实时的更新changelog日志）。如果存在metaloggers的话，主要的二进制文件以及日志也复制到metaloggers中。
在我们的测试环境中（大约500 T的数据，2500万个文件，200万文件夹，分成2600万个块（chunks）分布在70机器上），chunkserver的CPU使用情况为（持续传输文件）约为15-20％，内存使用100MiB（和数据量的多少无关）。
master服务器CPU消耗约30％（每秒约1500次操作），使用了8G内存。 CPU负载取决于操作的次数，内存的使用取决于文件和文件夹的个数。
文件数据是以块（chunks）为单位（块的最大大小64MB以上）存储在数据服务器（chunkservers）上的指定磁盘上。每个chunks存储在不同的机器上，但总数等于设定的“goal”
Master最重要的因素就是内存，因为整个文件系统结构都缓存到内存中以便加快访问速度。除了内存要求大，mfsmaster机器还需要一定硬盘大小用来存储Metadata数据和增长的日志文件。
Metadata文件的大小是取决于文件数的多少（而不是他们的大小）。changelog日志的大小是取决于每小时操作的数目，但是这个时间长度（默认是按小时）是可配置的。
100万文件大约需要300M内存。2500万份文件大约需要8G内存和25G硬盘空间。
master主要文件
mfsmaster.cfg
参数说明如下：
#WORKING_USER和WORKING_GROUP：是运行master server的用户和组；
#SYSLOG_IDENT：是master server在syslog中的标识，也就是说明这是由master server产生的；
#LOCK_MEMORY：是否执行mlockall()以避免mfsmaster 进程溢出（默认为0，即否）；
#NICE_LEVE：运行的优先级(如果可以默认是 -19; 注意: 进程必须是用root启动)；
#EXPORTS_FILENAME：被挂接目录及其权限控制文件的存放位置
#DATA_PATH：metadata files and lock file存放路径，此目录下大致有以下文件：metadata，changelog，sessions，stats，lock。
#BACK_LOGS：metadata的change log文件数目(默认是 50);
#REPLICATIONS_DELAY_INIT：(initial delay in seconds before starting replications)初始延迟复制的时间（默认是300s）;
#REPLICATIONS_DELAY_DISCONNECT：(replication delay in seconds after chunkserver disconnection） chunkserver断开后复制延迟（默认是3600s）；
# MATOML_LISTEN_HOST：用于metalogger连接的IP地址(默认是*，代表任何IP)；
# MATOML_LISTEN_PORT：监听metalogger请求的端口地址(默认是9419)；
# MATOCS_LISTEN_HOST：用于chunkserver连接的IP地址（默认是*，代表任何IP）；
# MATOCS_LISTEN_PORT：监听chunkserver连接的端口地址（默认是9420）；
# MATOCU_LISTEN_HOST：用于客户端挂接连接的IP地址(默认是*，代表任何IP)；
# MATOCU_LISTEN_PORT：监听客户端挂载连接的端口地址（默认是9421）；
# CHUNKS_LOOP_TIME ：（Chunks loop frequency in seconds）chunks的回环频率（默认是：300秒）；
# CHUNKS_DEL_LIMIT：（Maximum number of chunks to delete in one loop）在一个loop中可以删除chunks的最大数 (默认：100)
# CHUNKS_WRITE_REP_LIMIT：（Maximum number of chunks to replicate to one chunkserver in one loop）在一个loop里复制到一个chunkserver的最大chunk数目（默认是1）
# CHUNKS_READ_REP_LIMIT：（Maximum number of chunks to replicate from one chunkserver in one loop）在一个loop里从一个chunkserver复制的最大chunk数目（默认是5）
# REJECT_OLD_CLIENTS：弹出低于1.6.0的客户端挂接（0或1，默认是0）
mfsexports.cfg
MooseFS access control file
地址可以指定的几种表现形式：所有ip，单个ip，IP网络地址/位数掩码，IP网络地址/子网掩码，ip段范围。
权限部分：
ro 只读模式共享
rw 读写方式共享
alldirs 许挂载任何指定的子目录
maproot 映射为root，还是指定的用户
password 指定客户端密码
.mfsmaster.lock
master进程锁文件
metadata.mfs, metadata.mfs.back
MFS文件系统的元数据的镜像
changelog.*.mfs
changelog.*.mfs 是MFS文件系统元数据的改变日志（每小时合并到metadata.mfs中一次）
Metadata文件的大小取决于文件数（而不是他们的大小），Changelog的大小取决于每小时的操作次数。
2、metalogger
主要文件：
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 = 1 # 元数据下载间隔时间（默认是24小时，单位是小时，至多是BACK_LOGS的1/2）
# MASTER_RECONNECTION_DELAY = 5 # 失去连接之后延迟多少秒重新连接master
MASTER_HOST = 192.168.5.230
# MASTER_PORT = 9419
# MASTER_TIMEOUT = 60 #连接master超时时间（单位是秒）
# deprecated, to be removed in MooseFS 1.7
# LOCK_FILE = /var/run/mfs/mfsmetalogger.lock
.mfsmetalogger.lock
changelog_ml.*.mfs
MooseFS filesystem metadata change logs (backup of master change log files)
MFS文件系统的元数据changelog日志（备份Master的changelog日志。）
metadata.ml.mfs.back
Latest copy of complete metadata.mfs.back file from MooseFS master.
最近一次从Master上完全复制metadata.mfs.back（备份master的metadata.mfs.back）
sessions.ml.mfs
Latest copy of sessions.mfs file from MooseFS master.
最近一次从Master上完全复制sessions.mfs（备份master的sessions.mfs）
3、chunker
主要文件：
mfschunkserver.cfg
# WORKING_USER = mfs
# WORKING_GROUP = mfs
# SYSLOG_IDENT = mfschunkserver
# LOCK_MEMORY = 0
# NICE_LEVEL = -19
# DATA_PATH = /usr/local/mfs/var/mfs
# MASTER_RECONNECTION_DELAY = 5 （
MASTER_HOST = 192.168.5.230 元数据服务器的名称或地址，可以是主机名，也可以是ip地址。只要数据存储服务器能访问到元数据服务器就行。
# MASTER_PORT = 9420
# MASTER_TIMEOUT = 60
# CSSERV_LISTEN_HOST = *
# CSSERV_LISTEN_PORT = 9422
# CSSERV_TIMEOUT = 5
# HDD_CONF_FILENAME = /usr/local/mfs/etc/mfshdd.cfg #分配给MFS使用的磁盘空间配置文件的位置
# HDD_TEST_FREQ = 10 #chunk test period in seconds
# deprecated, to be removed in MooseFS 1.7
# LOCK_FILE = /var/run/mfs/mfschunkserver.lock
# BACK_LOGS = 50
mfshdd.cfg
mfschunkserver.lock
lock file of running MooseFS chunkserver process
4、mfsmount
三、MFS读写性能：
简单测试结果：
写：time dd if=/dev/zero of=/usr/mfstest/test2/zhhtest500M bs=1024k count=500
读：time dd if=/usr/mfstest/test2/zhhtest500M of=/dev/null
1copy写
2copy写
1copy读
2copy读
1M
0m0.042s
0m0.042s
0m0.017s
0m0.017s
2M
0m0.056s
0m0.066s
0m0.030s
0m0.055s
5M
0m0.073s
0m0.079s
0m0.070s
0m0.071s
10M
0m0.119s
0m0.131s
0m0.136s
0m0.197s
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
5G
4m41.956s
9m34.798s
2m9.200s
1m56.183s
10G
9m29.037s
19m26.237s
3m55.222s
3m24.914s
100G
95m53.500s
195m7.173s
32m4.295s
41m26.995s
总结规律：
1、读速度：ca 71M/s 写速度：ca 22M/s 9M/s （以500M计算）粗略测试，不太准确。
2、goal的设置和读写速度的关系？官方说goal和读写速度没有关系，但实际测试中goal越大，写速度越慢。
原始的读/写速度很明显主要取决于所使用的硬盘的性能、网络的容量和拓扑结构，使用的硬盘和网络的吞吐量越好，整个系统的性能也就会越好。
在我们的测试环境中，商业服务器（还做了其他较大量的计算），使用Debian操作系统，设置存储的份数为2，简单的千兆网络，使用P级别的数据，测试的结果：写速度大约在20-30MB/s，读速度为30-50MB/s。对于小文件写速度有些下降，但是对于读速度是没有影响的。
一般来说，goal不会影响读写速度。在一定条件下，存储份数的设置会影响的读取的速度。例如，多个客户端同时请求同一个文件，设置goal为2比1的读取速度快。但是在真实的环境中，多个客户端同时读取同一个文件的机率是比较小的，因此，存储份数的设置对读取的速度影响是比较小的。
同样，设置存储份数对写速度影响也是不太大。
四、灾难测试、恢复及其他测试
1、client 机器无论怎样操作都不会影响master。
客户端强制kill -9杀掉mfsmount进程，需要先umount，然后再mount。否则会提示：
fuse: bad mount point `/usr/mfstest/‘: Transport endpoint is not connected
see: /usr/local/mfs/bin/mfsmount -h for help
2、matser、metalogger、chunker、client端，服务器关机（init0）和重启（init6）时，程序都是正常关闭，无需修复。
3、master启动后，metalogger、chunker、client三个元素都能自动与master建立连接。
正常启动顺序：matser---chunker---metalogger---client
关闭顺序：client---chunker---metalogger---master
但实际中无论如何顺序启动或关闭，未见任何异常。
4、整个mfs体系中，直接断电只有master有可能无法启动。
使用mfsmetarestore -a修复才能启动，如果无法修复，使用metalogger上的备份日志进行恢复。（几次测试发现：如果mfsmetarestore -a无法修复，则使用metalogger也无法修复）。
强制使用metadata.mfs.back创建metadata.mfs，可以启动master，但应该会丢失1小时的数据。
mfs开发小组针对此问题回信：明确表示会丢失故障点到上一个整点之间的数据。和之前我猜测的一致。因为对mfs的操作日志都记录到changelog.0.mfs里面。changelog.0.mfs每小时合并一次到metadata.mfs中，如果突然断电，则changelog.0.mfs里面的信息就没有合并到metadata中，强制使用metadata.mfs.back创建metadata.mfs，就会导致丢失changelog.0.mfs里的数据。
直接断电测试过程，使用mfsmetarestore –a无法修复，使用metalogger也无法修复的情况较少发生。5次只有一次无法修复。
5、chunker的维持：chunker的块（chunks）能够自动复制或删除
对一个目录设定“goal”，此目录下的新创建文件和子目录均会继承此目录的设定，但不会改变已经存在的文件及目录的copy份数。但使用-r选项可以更改已经存在的copy份数。
goal设置为2，只要两个chunker有一个能够正常运行，数据就能保证完整性。
假如每个文件的goal（保存份数）都不小于2，并且没有under-goal文件（可以用mfsgetgoal –r和mfsdirinfo命令来检查），那么一个单一的chunkserver在任何时刻都可能做停止或者是重新启动。以后每当需要做停止或者是重新启动另一个chunkserver的时候，要确定之前的chunkserver被连接，而且要没有under-goal chunks。
实际测试时，传输一个大文件，设置存储2份。传输过程中，关掉chunker1，这样绝对会出现有部分块只存在chunker2上；启动chunker1，关闭chuner2，这样绝对会有部分块只存在chuner1上。
把chunker2启动起来。整个过程中，客户端一直能够正常传输。
在客户端查看，一段时间内，无法查看；稍后一段时间后，就可以访问了。文件正常，使用mfsfileinfo 查看此文件，发现有的块分布在chunker1上，有的块分布在chuner2上。
使用mfssetgoal 2和mfssetgoal -r 2均不能改变此文件的目前块的现状。
但使用mfssetgoal -r 1后，所有块都修改成1块了，再mfssetgoal -r 2，所有块都修改成2份了。
测试chunker端，直接断电情况下，chunker会不会出问题：
a、数据传输过程中，关掉chunker1，等待数据传输完毕后，开机启动chunker1.
chunker1启动后，会自动从chunker2复制数据块。整个过程中文件访问不受影响。
b、数据传输过程中，关掉chunker1，不等待数据传输完毕，开机启动chunker1.
chunker1启动后，client端会向chunker1传输数据，同时chunker1也从chunker2复制缺失的块。
如果有三台chunker，设置goal=2，则随机挑选2个chunker存储。
如果有一个chunker不能提供服务，则剩余的2个chunker上肯定有部分chunks保存的是一份。则在参数（REPLICATIONS_DELAY_DISCONNECT = 3600）后，只有一份的chunks会自动复制一份，即保存两份。
保存两份后，如果此时坏掉的chunker能够提供服务后，此时肯定有部分chunks存储了三份，mfs会自动删除一份。
当我增加第三个服务器做为额外的chunkserver时，虽然goal设置为2，但看起来第三个chunkserver从另外两个chunkserver上复制数据。
是的，硬盘空间平衡器是独立地使用chunks的，因此一个文件的chunks会被重新分配到所有的chunkserver上。
6、chunks修复 ：mfsfilerepair
mfsfilerepair用来处理坏文件（如读操作引起的I/O错误），使文件能够部分可读。在丢失块的情况下使用0对丢失部分进行填充；在块的版本号（version）不匹配时设置块的版本号为master上已知的能在chunkerservers找到的最高版本号；注意：因为在第二种情况下，可能存在块的版本号一样，但内容不匹配，因此建议在文件修复后，对文件进行拷贝（不是快照！），并删除原始文件。
Client端大文件传输过程中，强制拔下master主机电源，造成master非法关闭，使用mfsmetarestore -a修复后，master日志报告有坏块：
Jan 19 17:22:17 ngmaster mfsmaster[3250]: chunkserver has nonexistent chunk (000000000002139F_00000001), so create it for future deletion
Jan 19 17:22:18 ngmaster mfsmaster[3250]: (192.168.5.232:9422) chunk: 000000000002139F creation status: 20
Jan 19 17:25:18 ngmaster mfsmaster[3250]: chunk 000000000002139F has only invalid copies (1) - please repair it manually
Jan 19 17:25:18 ngmaster mfsmaster[3250]: chunk 000000000002139F_00000001 - invalid copy on (192.168.5.232 - ver:00000000)
Jan 19 17:26:43 ngmaster mfsmaster[3250]: currently unavailable chunk 000000000002139F (inode: 135845 ; index: 23)
Jan 19 17:26:43 ngmaster mfsmaster[3250]: * currently unavailable file 135845: blog.xxx.cn-access_log200904.tar.gz
Client端使用mfsfilerepair修复
[[email protected] mfstest]# /usr/local/mfs/bin/mfsfilerepair blog.xxx.cn-access_log200904.tar.gz
blog.xxt.cn-access_log200904.tar.gz:
chunks not changed: 23
chunks erased: 1
chunks repaired: 0
查看master日志，发现：
Jan 19 17:30:17 ngmaster mfsmaster[3250]: chunk hasn‘t been deleted since previous loop - retry
Jan 19 17:30:17 ngmaster mfsmaster[3250]: (192.168.5.232:9422) chunk: 000000000002139F deletion status: 13
Jan 19 17:35:16 ngmaster mfsmaster[3250]: chunk hasn‘t been deleted since previous loop - retry
Jan 19 17:35:16 ngmaster mfsmaster[3250]: (192.168.5.232:9422) chunk: 000000000002139F deletion status: 13
Client端执行以下操作后，master不再报告相关信息：
mv blog.xxt.cn-access_log200904.tar.gz blog.xxt.cn-access_log200905.tar.gz
7、chunker的空间
每一个chunkserver的磁盘都要为增长中的chunks保留些磁盘空间，从而达到创建新的chunk。只有磁盘都超过256M并且chunkservers报告自由空间超过1GB总量才可以被新的数据访问。最小的配置,应该从几个G 字节的存储。
每个chunkerserver每次以256M的磁盘空间进行申请，客户端查看得到的磁盘总使用情况的是每个chunkerserver使用量的总和。例如：如果你有3个chunkerserver，7个分区磁盘，每次你的硬盘使用会增加3*7*256MB (大约5GB)。假如你有150T的硬盘空间，磁盘空间就不用过多考虑了。
另外，如果你的chunkservers使用专用的磁盘，df将显示正确的磁盘使用情况。但是如果你有其他的数据在你的MooseFS磁盘上，df将会计算你所有的文件。
如果你想看你的MooseFS文件的使用情况，请使用‘mfsdirinfo‘命令。
8、快照snapshot
可以快照任何一个文件或目录，语法：mfsmakesnapshot src dst
但是src和dst必须都属于mfs体系，即不能mfs体系中的文件快照到其他文件系统。both elements must be on the same device。
Mfsappendchunks：追加chunks到一个文件
snapshot测试：
a、对一个文件做snapshot后，查看两个文件的块，是同一个块。把原文件删除，原文件删除后（回收站中最初可以看到，但一段时间后，回收站中就彻底删除了），snapshot文件仍然存在，并且可以访问。使用mfsfileinfo查看，发现仍然是原来的块。
b、对一个文件做snapshot后，查看两个文件的块，是同一个块。把原文件修改后，发现原文件使用的块名变了，即使用的是一个新块。而snapshot文件仍然使用原来的块。
9、回收站 trash bin
设置文件或目录的删除时间。一个删除的文件能够存放在“ 垃圾箱”中的时间称为隔离时间， 这个时间可以用mfsgettrashtime 命令来查看，用mfssettrashtime 命令来设置。单位为秒。
单独安装或挂载MFSMETA 文件系统（mfsmount -m mountpoint），它包含目录/ trash (包含仍然可以被还原的删除文件的信息)和/ trash/undel (用于获取文件)。
把删除的文件，移到/ trash/undel下，就可以恢复此文件。
在MFSMETA 的目录里，除了trash 和trash/undel 两个目录，还有第三个目录reserved，该目录内有已经删除的文件，但却被其他用户一直打开着。在用户关闭了这些被打开的文件后，reserved 目录中的文件将被删除，文件的数据也将被立即删除。此目录不能进行操作。
10、文件描述符
1.5.12版本，进行大量小文件写时，出现了一个严重错误，有可能和操作系统文件描述符有关。操作系统默认文件描述符为1024.
1.6.11版本默认为100000
建议上线时，master和chunker修改文件描述符，即修改/etc/security/limits.conf添加
* - nofile 65535
11、mfscgiserv
Mfscgiserv 是一个python 脚本， 它的监听端口是9425 ，使用/usr/local/mfs/sbin/mfscgiserv 来直接启动，使用浏览器就可全面监控所有客户挂接， chunkserver 及master server，客户端的各种操作等。