MFS学习总结
- MFS概述、特性和新版改进
- MFS 工作原理和设计架构
- MFS的安装、部署、配置
- MFS的高级特性
- MFS的性能测试
- MFS集群的维护
- MFS的常见问题和建议对策
一、MFS概述、特性和新版改进
MooseFS是一个分布式存储的框架，其具有如下特性：
- Free(GPL)
- 通用文件系统，不需要修改上层应用就可以使用（那些需要专门api的dfs很麻烦！）。
- 可以在线扩容，体系架构可伸缩性极强。（官方的case可以扩到70台了！）
- 部署简单。（sa们特别高兴，领导们特别happy！）
- 高可用，可设置任意的文件冗余程度（提供比raid1+0更高的冗余级别，而绝对不会影响读或者写的性能，只会加速！）
- 可回收在指定时间内删除的文件（“回收站”提供的是系统级别的服务，不怕误操作了，提供类似oralce 的闪回等高级dbms的即时回滚特性！）
- 提供netapp，emc，ibm等商业存储的snapshot特性。（可以对整个文件甚至在正在写入的文件创建文件的快照）
- google filesystem的一个c实现。
- 提供web gui监控接口。
- 提高随机读或写的效率（有待进一步证明）。
- 提高海量小文件的读写效率（有待进一步证明）。
MooseFS 1.6版本改进：
- 修复1.5.x中在大批量操作时打开文件过多的bug。报的错误说是打开的文件过多，造成chunker server的链接错误。在1.6.x中解决此问题，就解决了很大的问题。
- 新增加了masterlogger服务器。这是在1.5.x中所没有的，就是做了master服务器的冗余，进一步的加强的master服务器的稳定性。在mfs体系中master是要求最稳定以及性能要求最高的，因此务必保证master的稳定。
- 修改1.5.x中存在的对于坏块的修复功能。在mfs1.5.x中遇到chunker坏块校验，错误比较多的时候导致master将出现坏块的chunker自动的剔除出去的情况，此次增加了对坏块的修复功能，很方便的进行修复，简化对坏块的处理功能。
- 对metadata和changelog的新认识。之前认为changelog记录的是文件的操作，定期的像数据库的日志一样归档到metadata中。发现上面的理解存在误区，真正的是changelog中记录了对文件的操作，metadata记录文件的大小和位置。因此metadata是比较重要的，在进行修复的过程中是采用metadata和最后一次的changelog进行修复的。
- MFS文档中明确指出对于内存和磁盘大小的要求。
- 指出了在测试的过程中多个chunker并不影响写的速度，但是能加快读的速度。在原来的基础上增加一个chunker时，数据会自动同步到新增的chunker上以达到数据的平衡和均衡。
二、MFS 工作原理和设计架构
| 角色 | 角色作用 |
| 管理服务器 | 负责各个数据存储服务器的管理,文件读写调 |
| 元数据日志服务器 | 负责备份master 服务器的变化日志文件，文 |
| 数据存储服务器 | 负责连接管理服务器,听从管理服务器调度, |
| 客户机挂载使用 | 通过fuse 内核接口挂接远程管理服务器上所 |
官方的网络示意图是这样的：
读写原理：
MFS的读数据过程
- client当需要一个数据时，首先向master server发起查询请求；
- 管理服务器检索自己的数据，获取到数据所在的可用数据服务器位置ip|port|chunkid；
- 管理服务器将数据服务器的地址发送给客户端；
- 客户端向具体的数据服务器发起数据获取请求；
- 数据服务器将数据发送给客户端；
MFS的写数据过程
- 当客户端有数据写需求时，首先向管理服务器提供文件元数据信息请求存储地址（元数据信息如：文件名|大小|份数等）；
- 管理服务器根据写文件的元数据信息，到数据服务器创建新的数据块；
- 数据服务器返回创建成功的消息；
- 管理服务器将数据服务器的地址返回给客户端(chunkIP|port|chunkid)；
- 客户端向数据服务器写数据；
- 数据服务器返回给客户端写成功的消息；
- 客户端将此次写完成结束信号和一些信息发送到管理服务器来更新文件的长度和最后修改时间
MFS的删除文件过程
- 客户端有删除操作时，首先向Master发送删除信息；
- Master定位到相应元数据信息进行删除，并将chunk server上块的删除操作加入队列异步清理；
- 响应客户端删除成功的信号
MFS修改文件内容的过程
- 客户端有修改文件内容时，首先向Master发送操作信息；
- Master申请新的块给.swp文件，
- 客户端关闭文件后，会向Master发送关闭信息；
- Master会检测内容是否有更新，若有，则申请新的块存放更改后的文件，删除原有块和.swp文件块；
- 若无，则直接删除.swp文件块。
MFS重命名文件的过程
- 客户端重命名文件时，会向Master发送操作信息；
- Master直接修改元数据信息中的文件名；返回重命名完成信息；
MFS遍历文件的过程
- 遍历文件不需要访问chunk server，当有客户端遍历请求时，向Master发送操作信息；
- Master返回相应元数据信息；
- 客户端接收到信息后显示
注：
- Master记录着管理信息，比如：文件路径|大小|存储的位置(ip,port,chunkid)|份数|时间等，元数据信息存在于内存中，会定期写入metadata.mfs.back文件中，定期同步到metalogger，操作实时写入changelog.*.mfs，实时同步到metalogger中。master启动将metadata.mfs载入内存，重命名为metadata.mfs.back文件。
- 文件以chunk大小存储，每chunk最大为64M，小于64M的，该chunk的大小即为该文件大小（验证实际chunk文件略大于实际文件），超过64M的文件将被切分，以每一份（chunk）的大小不超过64M为原则；块的生成遵循规则：目录循环写入(00-FF 256个目录循环，step为2)、chunk文件递增生成、大文件切分目录连续。
- Chunkserver上的剩余存储空间要大于1GB（Reference Guide有提到），新的数据才会被允许写入，否则，你会看到No space left on device的提示，实际中，测试发现当磁盘使用率达到95%左右的时候，就已经不行写入了，当时可用空间为1.9GB。
- 文件可以有多份copy，当goal为1时，文件会被随机存到一台chunkserver上，当goal的数大于1时，copy会由master调度保存到不同的chunkserver上，goal的大小不要超过chunkserver的数量，否则多出的copy，不会有chunkserver去存。
三、MFS的安装、部署、配置
测试环境：
| IP | 作用 |
| 192.168.0.1 | master server |
| 192.168.0.2 | metalogger server |
| 192.168.0.3 | chunk server |
| 192.168.0.4 | chunk server |
| 192.168.0.5 | chunk server |
| 192.168.0.6 | mfs client |
3.1 Master Server
在192.168.0.1进行如下操作：
3.1.1 安装:
$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-mfschunkserver --disable-mfsmount
$make
$make install
$cd /usr/local/mfs/etc
$cp mfsmaster.cfg.dist mfsmaster.cfg #主配置文件
$cp mfsexports.cfg.dist mfsexports.cfg #被挂接目录及权限配置
3.1.2配置：
$vi /usr/local/mfs/etc/mfsmaster.cfg
# WORKING_ USER = mfs #运行master server 的用户
# WORKING_ GROUP = mfs #运行master server 的组
# SYSLOG_IDENT = mfsmaster #master server 在syslog 中的标识，说明是由master serve 产生的
# LOCK_MEMORY = 0 #是否执行mlockall()以避免mfsmaster 进程溢出（默认为0）
# NICE_LEVEL = -19 #运行的优先级(如果可以默认是-19; 注意: 进程必须是用root 启动)
# EXPORTS_FILENAME = /usr/local/mfs/etc/mfsexports.cfg #被挂接目录及其权限控制文件的存放位置
# DATA_PATH = /usr/local/mfs/var/mfs #数据存放路径，此目录下大致有三类文件，changelog，sessions 和stats；
# BACK_LOGS = 50 #metadata 的改变log 文件数目(默认是50);
# REPLICATIONS_ DELAY_INIT = 300 #延迟复制的时间（默认是300s）;
# REPLICATIONS_ DELAY_DISCONNECT = 3600 #chunkserver 断开的复制延迟（默认是3600）；
# MATOML_LISTEN_HOST = * #metalogger 监听的IP 地址(默认是*，代表任何IP)；
# MATOML_LISTEN_PORT = 9419 #metalogger 监听的端口地址(默认是9419)；
# MATOCS_LISTEN_ HOST = * #用于chunkserver 连接的IP 地址（默认是*，代表任何IP）；
# MATOCS_LISTEN_PORT = 9420 #用于chunkserver 连接的端口地址（默认是9420）；
# MATOCU_LISTEN_HOST = * #用于客户端挂接连接的IP 地址(默认是*，代表任何IP)；
# MATOCU_LISTEN_PORT = 9421 #用于客户端挂接连接的端口地址（默认是9421）；
# CHUNKS_LOOP_TIME = 300 #chunks 的回环频率（默认是：300 秒）；# CHUNKS_DEL_LIMIT = 100
# CHUNKS_WRITE_REP_LIMIT = 1 #在一个循环里复制到一个chunkserver 的最大chunk 数目（默认是1）
# CHUNKS_READ_REP_LIMIT = 5 #在一个循环里从一个chunkserver 复制的最大chunk 数目（默认是5）
# REJECT_OLD_ CLIENTS = 0 #弹出低于1.6.0 的客户端挂接（0 或1，默认是0）
注意：
- 凡是用#注释掉的变量均使用其默认值
- 修改DATA_PATH指定的目录要权限为mfs，chown -R mfs:mfs /usr/local/mfs/var/mfs
- mfsexports 访问控制对于那些老客户是没用的
- 注意开通监听的端口
$vi /usr/local/mfs/etc/mfsexports.cfg
#客户端IP 允许挂载的目录 客户端拥有的权限
192.168.0.0/24 / rw,alldirs,maproot=0 # /标识MFS的根
192.168.0.0/24 . rw # .标识MFSMETA 文件系统
地址可以指定的格式：
| IP格式 | 说明 |
| * | 所有的ip 地址 |
| n.n.n.n | 单个ip 地址 |
| n.n.n.n/b | IP 网络地址/位数掩码 |
| n.n.n.n/m.m.m.m | IP 网络地址/子网掩码 |
| f.f.f.f-t.t.t.t | IP 段 |
权限说明：
| 权限 | 说明 |
| ro | 只读模式 |
| rw | 读写模式 |
| alldirs | 许挂载任何指定的子目录 |
| maproot | 映射为root，还是指定的用户 |
| password | 指定客户端密码 |
3.1.3 操作：
$/usr/local/mfs/sbin/mfsmaster [-vdu] [-t locktimeout] [-c cfgfile] [start|stop|restart|reload] #master服务操作
$/usr/local/mfs/sbin/mfscgiserv #启动WEBUI 监控服务，访问http://192.168.0.1:9425/
注意：
最好不要kill master，安全停止执行mfsmaster stop，否则下次启动因metadata.mfs.back而出现问题，还需要使用备份来恢复。
文件说明：
$ls -l /usr/local/mfs/var/mfs #此目录见mfsmaster.cfg中DATA_PATH配置
metadata.mfs.back #MFS元数据信息，延迟将内存数据写入文件，默认频率1h，默认1d同步一次此文件到metalogger server
changelog.*.mfs #文件操作日志记录，实时记录、同步到metalogger server
sessions.mfs #客户操作状态记录
stats.mfs #？
3.1.4备注：
- 用户操作日志见：changelog.*.mfs
- 进程产生的日志放到系统日志中：/var/log/messages
- Master可以单独启动，注意开通监听的端口
3.2 Chunk Server
在192.168.0.3-在192.168.0.5 进行如下操作
3.2.1安装：
$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-mfsmount
$make
$make install
$cd /usr/local/mfs/etc
$cp mfschunkserver.cfg.dist mfschunkserver.cfg #chunk配置文件
$cp mfshdd.cfg.dist mfshdd.cfg #MFS使用空间配置
3.2.2配置：
$vi /usr/local/mfs/etc/mfschunkserver.cfg
# WORKING_USER = mfs
# WORKING_GROUP = mfs
# DATA_PATH = /usr/local/mfs/var/mfs
# LOCK_FILE = /var/run/mfs/mfschunkserver.pid
# SYSLOG_IDENT = mfschunkserver
# BACK_LOGS = 50
# MASTER_RECONNECTION_DELAY = 30
MASTER_HOST = 192.168.0.1 #元数据服务器的名称或地址，可以是主机名，也可以是ip 地址
# MASTER_PORT = 9420 #为Matser中 MATOCS_LISTEN_PORT指定的端口
# MASTER_TIMEOUT = 60
# CSSERV_LISTEN_HOST = *
# CSSERV_LISTEN_PORT = 9422 这个监听端口用于与其它数据存储服务器间的连接，通常是数据复制
# CSSERV_TIMEOUT = 60
# CSTOCS_TIMEOUT = 60
# HDD_CONF_FILENAME = /usr/local/mfs/etc/mfshdd.cfg 分配给MFS 使用的磁盘空间配置文件的位置
注意：
- MASTER_HOST 不能为localhost或127.0.0.1，做单机测试的童鞋们注意了，要使用对外IP。
- MASTER_PORT必须为元数据服务器配置中MATOCS_LISTEN_PORT指定的端口，且IP必须被master允许。
- 注意开通监控的端口(这里是9422)
$chown -R mfs:mfs /data #没有这一操作，会出现写权限问题，因进程是用mfs运行的。
$vi /usr/local/mfs/etc/mfshdd.cfg
/data
注意：
- 在这里/data 是一个给mfs 的分区，但在本机上是一个独立的目录，最好是一个单独的硬盘或者一个raid 卷，最低要求是一个分区。
- 不要忘了更改目录的权限，因为mfschunkserver进程是用mfs运行的。
3.2.3操作
/usr/local/mfs/sbin/mfschunkserver [-vdu] [-t locktimeout] [-c cfgfile] [start|stop|restart|reload] #chunkserver操作命令
3.3 MetaLogger Server
在192.168.0.2上执行如下操作：
3.3.1安装：
同Master的安装步骤。
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文件系统使用手册》
)
。...)
(简单解构)(map对象遍历)(可变顺序参数和不可以变顺序参数函数))
