客户端工具集
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，但丢失的数据暂无法确定
的用户搜索实现)
)
