客户端工具集

	mfsgetgoal		#设定副本数
	mfssetgoal		#获取副本数
	mfscopygoal		#
	mfsgetsclass
	mfssetsclass
	mfscopysclass
	mfsxchgsclass
	mfslistsclass
	mfsgettrashtime		#设定回收站时间
	mfssettrashtime		#设定回收站时间
	mfscopytrashtime
	mfsgeteattr		#设置权限
	mfsseteattr		#获取权限
	mfsdeleattr
	mfscopyeattr
	mfsgetquota
	mfssetquota
	mfsdelquota
	mfscopyquota
	mfscheckfile		#检查文件
	mfsfileinfo		#文件信息
	mfsappendchunks
	mfsdirinfo		#目录信息
	mfsfilerepair		#文件修复
	mfsmakesnapshot		#快照
	mfsfilepaths
	mfschkarchive
	mfssetarchive
	mfsclrarchive
	mfsscadmin

deprecated tools:                                  // 递归设置
        mfsrgetgoal = mfsgetgoal -r
        mfsrsetgoal = mfssetgoal -r
        mfsrgettrashtime = mfsgettreshtime -r
        mfsrsettrashtime = mfssettreshtime -r

mfsmaster运行目录下的文件介绍

     metadata.mfs.back  #MFS元数据信息，延迟将内存数据写入文件，默认频率1h，默认1d同步一次此文件到metalogger server
      changelog.*.mfs      #文件操作日志记录，实时记录、同步到metalogger server
      sessions.mfs  #客户操作状态记录
      stats.mfs        #？

mfsmaster的权限管理（类似于nfs的exports文件）

	vi /etc/mfs/mfsexports.cfg

#客户端IP        允许挂载的目录  客户端拥有的权限
192.168.1.5     /            rw,alldirs,maproot=0  # /标识MFS的根(读写的方式共享，允许挂载任何指定的子目录)
192.168.0.0/24     .         rw                    # .标识MFSMETA 文件系统
	
#客户端			#目录部分需要注意两点			#权限部分
#*　所有客户机		/ 标识MooseFS 根				ro　只读模式共享
#f.f.f.f 单个主机		. 表示MFSMETA 文件系统			rw　读写的方式共享
#f.f.f.f/p 某个子网段						alldirs 允许挂载任何指定的子目录
#f.f.f.f-d.d.d.d 某两个ip段区间					maproot 映射为root，还是指定的用户
								password 指定客户端密码

客户端挂载文件系统（使用命令：mfsmount）

mfsmount可用参数
	-H	#接管理服务器IP
	-P	#接管理服务器端口
	-S	#指出被挂接mfs 目录的子目录，默认是/目录，就是挂载整个mfs 目录
	-m	#这样可以挂载一个辅助的文件系统mfsmeta，辅助文件系统可以在如下两个方面恢复丢失的数据

设定数据副本数量

#设定数据副本数量
	#在客户挂载好的目录下创建，两个用于测试的目录
	mkdir /data/test{1,2}

	#设置存放文件的份数
	mfssetgoal 1 /data/test1	#注意：对于已经存在的文件不会改变其副本数，只对后续新写入的文件副本数生效
	mfssetgoal -r 2 /data/test2	#此时所有已存在的文件及子目录副本数为2，并且新写入的文件和子目录的副本数也为2

	#注意若是空文件，那么在后端chunk上是不会创建文件的，只会出现在元数据中
	#注意：文件及目录所保留的真实副本数是依据数据存储服务器的数量，如果数据存储服服务器只有两台，但却为文件及目录设定了3个副本的话，最后的真实副本数为2

	#复制文件到对应的目录
	cp /etc/hosts /data/test1
	cp /etc/hosts /data/test2

	#验证1
[root@client68 ~]# mfsfileinfo /data/test1/hosts 
/data/test1/hosts:
	chunk 0: 0000000000000029_00000001 / (id:41 ver:1)
		copy 1: 192.168.1.65:9422 (status:VALID)

[root@client68 ~]# mfsfileinfo /data/test2/hosts 
/data/test2/hosts:
	chunk 0: 000000000000002A_00000001 / (id:42 ver:1)
		copy 1: 192.168.1.66:9422 (status:VALID)
		copy 2: 192.168.1.67:9422 (status:VALID)

	#验证2
[root@client68 ~]# mfsgetgoal /data/
/data/: 2
[root@client68 ~]# mfsgetgoal /data/test1
/data/test1: 1
[root@client68 ~]# mfsgetgoal /data/test2
/data/test2: 2

设定垃圾回收站，回收时间（使用命令：mfssettrashtime　，可以使用-r 参数递归）

	#一个被删除文件能够存放在一个“ 垃圾箱”的时间就是一个隔离时间， 这个时间可以用 mfsgettrashtime 命令来验证，也可以使用`mfssettrashtime 命令来设置

	#设置删除文件最长保留时间，单位为秒（0：表示立即彻底删除，1小时：3600；1天：86400；一周：604800；1月：2592000）
	mfssettrashtime 64800 /data/test1	

	mfsgettrashtime /data/test1		#获取删除文件最长保留时间（验证）

快照snapshot（使用命令：mfsmakesnapshot）

快照snapshot（使用命令：mfsmakesnapshot）
	#可以给任何一个文件或目录树做快照，前提是必须是在mfs体系里的
	#语法：mfsmakesnapshot src dst
	mfsmakesnapshot /data/test2/hosts /data/

	#是在一次执行中整合了一个或是一组文件的拷贝，而且任何修改这些文件的源文件都不会影响到源文件的快照， 就是说任何对源文件的操作,例如写入源文件，将不会修改副本

	a：对一个文件做snapshot后，查看两个文件的块，是同一个块。把原文件删除，原文件删除后（回收站中最初可以看到，但一段时间后，回收站中就彻底删除了），snapshot文件仍然存在，并且可以访问。使用mfsfileinfo查看，发现仍然是原来的块。

	b：对一个文件做snapshot后，查看两个文件的块，是同一个块。把原文件修改后，发现原文件使用的块名变了，即使用的是一个新块。而snapshot文件仍然使用原来的块。

如何在回收站（trash）中将删除的数据恢复

如何在回收站（trash）中将删除的数据恢复
	#思路：在垃圾箱有效时限内，挂载mfsmeta文件系统，定位到被删除的文件，将其移动到所在目录下的　undel　目录即可

	1：确保垃圾箱的回收时间稍大一点，方便做实验
[root@client68 undel]# mfsgettrashtime /data/test1/
/data/test1/: 86400

	2：创建文件，输入内容，然后保存，并删除
	touch /data/test1/hello
	echo "我们是共产主义接班人"　>> /data/test1/hello

	rm  /data/test1/hello

	3：先挂载mfsmeta文件系统
	mount -m -H 192.168.1.61 /tmp/ceshi

	4：定位文件（根据文件名）
[root@client68 ~]# find /tmp/ceshi/trash/ -name "*hello*"  
/tmp/ceshi/trash/00F/0000000F|test1|hello

	5：查看定位到文件内容（注意：一定要用单引号）
[root@client68 ~]# cat '/tmp/ceshi/trash/00F/0000000F|test1|hello'
test1/hello

	6：恢复文件成功（移动这个文件到文件所在目录下的undel下面，将会使原始的文件恢复到正确的MFS文件系统原来的路径下）
[root@client68 ~]# cd /tmp/ceshi/trash/00F
[root@client68 00F]# ls
0000000F|test1|hello  undel
[root@client68 00F]# pwd
/tmp/ceshi/trash/00F
[root@client68 00F]# mv 0000000F|test1|hello ./undel/
[root@client68 00F]# ls /data/test1/
hello
[root@client68 00F]# cat /data/test1/hello 
我们是共产主义接班人

	#注意：在恢复文件的时候，原来被删文件下面的目录下，不能有同名文件，不然恢复不成功

MFS元数据备份

通常元数据有两部分的数据：

	#主要元数据文件metadata.mfs，当mfsmaster 运行的时候会被命名为metadata.mfs.back
	元数据改变日志changelog.*.mfs，存储了过去的N 小时的文件改变（N 的数值是由BACK_LOGS参数设置的，参数的设置在mfschunkserver.cfg 配置文件中）。

	#主要的元数据文件需要定期备份，备份的频率取决于取决于多少小时changelogs 储存。元数据changelogs 实时的自动复制。1.6版本中这个工作都由metalogger完成。

MFSMaster的恢复

	#需要最后一个元数据日志changelog 并入主要的metadata 中。这个操作时通过 mfsmetarestore 工具做的
	#先修复（几次测试发现：如果mfsmetarestore -a无法修复，则使用metalogger也无法修复）
	mfsmetarestore -a

	#如果master 数据被存储在MooseFS 编译指定地点外的路径，则要利用-d 参数指定使用，如：
	mfsmetarestore -a -d /opt/mfsmaster

	#再启动(才能成功)

	#强制使用metadata.mfs.back创建metadata.mfs，可以启动master，但应该会丢失1小时的数据。
	#明确表示会丢失故障点到上一个整点之间的数据。和之前我猜测的一致。因为对mfs的操作日志都记录到changelog.0.mfs里面。changelog.0.mfs每小时合并一次到metadata.mfs中，如果突然断电，则changelog.0.mfs里面的信息就没有合并到metadata中，强制使用metadata.mfs.back创建metadata.mfs，就会导致丢失changelog.0.mfs里的数据。

从MetaLogger中恢复Master

	#在MetaLogger上，使用mfsmetarestore -a 命令,合并changelogs，然后将其角色提升为mfsmaster.
	#强制使用metadata.mfs.back创建metadata.mfs，可以启动master，但丢失的数据暂无法确定