How to build MFS Distributed File System? Theory + practical operation!

Foreword

A: MFS theoretical part

1.1: Introduction to Distributed

• Distributed File System (Distributed File System) refers to the physical storage resource file system management is not necessarily directly connected to the local node, but the node is connected to a computer network.
• It is simply put some scattered (distributed on individual computers within a local area network) shared folder, a collection to a folder (virtual shared folder). For the user, when you want to access the shared folders, just open the virtual shared folder, you can see all the links to shared files shared virtual folders within folders, users do not feel these shares are distributed among computers Up.
• The benefits of distributed file system is centralized access, simplify operation, data disaster recovery, improved file access performance

1.2: MFS principle

• MooseFS is a fault-tolerant distributed file system with the network. It is stored in the data dispersed across multiple physical servers, and presented to the user is a unified resource.

MFS file system consisting of: 1.2.1

• Metadata server (Master server)

  • A file system independent management of the entire host, the metadata stored for each file (size, attributes, location information file, including all information for all files unconventional, such as directory, socket, pipe, and the device file)

  • Responsible for managing the file system in the whole system, maintain metadata

• Metadata log / backup server (MetaLogger server)

  • Any number of servers used to store metadata and change logs periodically to download the main metadata file, in order to take over the position for good management server stops unexpectedly.

  • Backup Master server change log file, the file type changelog_ml. *. Mfs. When Master server data is lost or corrupted, you can obtain recovery from the log file server

• Data Storage Server (Chunk Server)

  • Any number of servers used to store metadata and change logs periodically to download the main metadata file, in order to take over the position for good management server stops unexpectedly.

  • Real server to store data. When storing a file, the file will save block, and copy the data between the server, the more data servers, can use the "capacity" of the larger, higher reliability, better performance.

• The client (Client)

  • Any number of hosts, it can (receive and change metadata) and data server (to change the actual file data) to communicate with the management server by mfsmount process.

  • Like NFS can mount the same mount MFS file system, its operation is the same.

• 

1.2.3: MFS reading processing data

• [1] The client issues a read request to the metadata server.
• [2] metadata server the required data storage location (Chunk Server IP address and Chunk number) tells the client.
• [3] is known to the client to request the data Chunk Server.
• [4] Chunk Server sends data to the client.
• 

1.2.4: MFS data writing process

• [1] The client sends the server the metadata write request.
• [2] After the metadata server to interact with Chunk Server (required only when there is a block Chunks of this interaction was conducted), but only the metadata server to create a new block Chunks in some servers, created by the success Servers success inform metadata server operations
• [3] metadata server tells the client, which can write data which Chunks Chunk Server in.
• [4] client to write data to the specified Chunk Server
• [5] The Chunk Server data synchronization with other Chunk Server
• [6] Data Synchronization success
• [7] After a successful synchronization Chunk Server tells the client data is written to success.
• [8] metadata server client informed of this writing has been completed.
• 

Two: MFS deployment experiment

2.1: Environment Introduction

• VMware Software

• Host computer	operating system	IP地址	主要软件
  Master Server	CentOS 7.6 x86_64	192.168.233.131	moosefs-3.0.100-1.tar.gz
  MetaLogger Server	CentOS 7.6 x86_64	192.168.233.132	moosefs-3.0.100-1.tar.gz
  Chunk Server1	CentOS 7.6 x86_64	192.168.233.133	moosefs-3.0.100-1.tar.gz
  Chunk Server2	CentOS 7.6 x86_64	192.168.233.128	moosefs-3.0.100-1.tar.gz
  Chunk Server3	CentOS 7.6 x86_64	192.168.233.129	moosefs-3.0.100-1.tar.gz
  Client	CentOS 7.6 x86_64	192.168.233.130	moosefs-3.0.100-1.tar.gz fuse-2.9.2.tar.gz

2.2：实验目的

• 多台Web服务器通过NFS共享一个存储，会有如下问题：
  • 1、业务功能上满足需求
  • 2、在性能与容量上无法胜任更高的要求
  • 3、NFS服务器不堪重负，出现超时问题
  • 4、NFS存在着单点故障问题
• 采用MFS解决以上问题
  • 1、采用分布式文件系统
  • 2、服务器之间的数据访问不再是一对多的关系，而是多对多的关系
  • 3、可以使性能得到大幅提升

2.3：拓扑图

• 

2.4：实验过程

• 六台服务器上关闭防火墙、关闭核心防护、配置主机名、配置hosts

• 此处仅展示client的操作

  [root@localhost ~]# hostnamectl set-hostname client	'//修改主机名'
  [root@localhost ~]# su
  [root@client ~]# systemctl stop firewalld	'//关闭防火墙'
  [root@client ~]# systemctl disable firewalld	'//取消开机自启动'
  Removed symlink /etc/systemd/system/multi-user.target.wants/firewalld.service.
  Removed symlink /etc/systemd/system/dbus-org.fedoraproject.FirewallD1.service.
  [root@client ~]# setenforce 0	'//关闭核心防护'
  [root@client ~]# vi /etc/sysconfig/selinux 
  SELINUX=disabled	'//取消开启自启动'
  [root@client ~]# vi /etc/hosts	'//修改本地主机映射文件'
  192.168.233.131	master
  192.168.233.132	metalogger
  192.168.233.133	chunk01
  192.168.233.128	chunk02
  192.168.233.129	chunk03
  192.168.233.130 client
  [root@client ~]# yum -y install gcc gcc-c++ zlib-devel	'//安装编译器'
  
  

2.4.1：搭建 MFSmaster

• 创建用户并编译安装源码包

  [root@master ~]# useradd -s /sbin/nologin -M mfs	'//创建用户'
  [root@master ~]# mount.cifs //192.168.11.1/ccc /mnt	'//挂载宿主机目录'
  Password for root@//192.168.11.1/ccc:  
  [root@master ~]# cd /mnt/mfs
  [root@master mfs]# tar zxvf moosefs-3.0.100-1.tar.gz -C /opt	'//解压源码包到/opt目录下'
  [root@master mfs]# cd /opt/moosefs-3.0.100/
  [root@master moosefs-3.0.100]# ./configure \	'//进行配置'
  > --prefix=/usr/local/mfs \	'//指定安装目录'
  > --with-default-user=mfs \	'//指定运行用户'
  > --with-default-group=mfs \	'//指定运行组'
  > --disable-mfschunkserver \	'//禁用chunk功能'
  > --disable-mfsmount	'//禁用mfsmount功能'
  [root@master moosefs-3.0.100]# make && make install	'//编译安装'
  
  

• 复制 master 配置文件

  [root@master opt]# cd /usr/local/mfs/etc/mfs/	'//进入mfs目录'
  [root@master mfs]# ls
  mfsexports.cfg.sample  mfsmaster.cfg.sample  mfsmetalogger.cfg.sample  mfstopology.cfg.sample
      '//将几个配置文件的模板复制一下'
  [root@master mfs]# cp mfsmaster.cfg.sample mfsmaster.cfg
  [root@master mfs]# cp mfsexports.cfg.sample mfsexports.cfg
  [root@master mfs]# cp mfstopology.cfg.sample mfstopology.cfg
  [root@master mfs]# cd /usr/local/mfs/var/mfs/
  [root@master mfs]# cp metadata.mfs.empty metadata.mfs
  [root@master mfs]# chown mfs:mfs /usr/local/mfs/var/mfs	'//设置目录的属主属组'
  [root@master mfs]# /usr/local/mfs/sbin/mfsmaster start	'//开启master server'
  [root@master mfs]# netstat -anpt | grep mfs	'//检测mfs是否开启'
  tcp        0      0 0.0.0.0:9419            0.0.0.0:*               LISTEN      41396/mfsmaster     
  tcp        0      0 0.0.0.0:9420            0.0.0.0:*               LISTEN      41396/mfsmaster     
  tcp        0      0 0.0.0.0:9421            0.0.0.0:*               LISTEN      41396/mfsmaster   
      '//停止 Master Server 的命令是/usr/local/mfs/sbin/mfsmaster stop'
  

2.4.2：搭建 MFS 日志服务器

• 相同方法编译安装源码包，并创建用户，此处不在赘述

• 复制 metalogger 主配置文件并编辑

  [root@metalogger moosefs-3.0.100]# cd /usr/local/mfs/etc/mfs
  [root@metalogger mfs]# ls
  mfsexports.cfg.sample  mfsmaster.cfg.sample  mfsmetalogger.cfg.sample  mfstopology.cfg.sample
  [root@metalogger mfs]# cp mfsmetalogger.cfg.sample mfsmetalogger.cfg
  [root@metalogger mfs]# vim mfsmetalogger.cfg	'//编辑日志配置文件'
   MASTER_HOST = 192.168.233.131	'//取消注释，指定master服务器地址'
  
  

• 启动mfs服务

  [root@metalogger mfs]# /usr/local/mfs/sbin/mfsmetalogger start
  open files limit has been set to: 4096
  working directory: /usr/local/mfs/var/mfs
  lockfile created and locked
  initializing mfsmetalogger modules ...
  mfsmetalogger daemon initialized properly
  [root@metalogger mfs]# netstat -anpt | grep mfs
  tcp        0      0 192.168.233.132:37252   192.168.233.131:9419    ESTABLISHED 51991/mfsmetalogger 
  
  

2.4.3：搭建 chunk 存储端

• 相同方法编译安装源码包，并创建用户，此处不在赘述

• 三台节点的操作都是相同的，此处仅展示一个节点的操作

• 复制 mfschunk 主配置文件并编辑

  [root@chunk01 moosefs-3.0.100]# cd /usr/local/mfs/etc/mfs/
  [root@chunk01 mfs]# ls
  mfschunkserver.cfg.sample  mfshdd.cfg.sample  mfsmetalogger.cfg.sample
  [root@chunk01 mfs]# cp mfschunkserver.cfg.sample mfschunkserver.cfg
  [root@chunk01 mfs]# cp mfshdd.cfg.sample mfshdd.cfg
  [root@chunk01 mfs]# vi mfschunkserver.cfg	'//编辑存储节点配置文件'
  MASTER_HOST = 192.168.100.40	'//指向master服务器地址'
  [root@chunk01 mfs]# vim mfshdd.cfg
  /data	'//添加一个挂载点目录'
  [root@chunk01 mfs]# mkdir /data	'//创建挂载点'
  [root@chunk01 mfs]# chown -R mfs:mfs /data	'//给挂载点属主属组'
  
  

• 启动mfs服务

  [root@chunk01 mfs]# /usr/local/mfs/sbin/mfschunkserver start
  [root@chunk01 mfs]# netstat -anpt | grep mfs
  tcp        0      0 0.0.0.0:9422            0.0.0.0:*               LISTEN      103672/mfschunkserv 
  tcp        0      0 192.168.233.133:49394   192.168.233.131:9420    ESTABLISHED 103672/mfschunkserv 
  

2.4.4：使用 MFS 挂在到客户端

• 安装 FUSE

  [root@master ~]# useradd -s /sbin/nologin -M mfs
  [root@master ~]# mount.cifs //192.168.11.1/ccc /mnt
  Password for root@//192.168.11.1/ccc:  
  [root@master ~]# cd /mnt/mfs
  [root@master mfs]# tar zxvf moosefs-3.0.100-1.tar.gz -C /opt
  [root@master mfs]# tar xzvf fuse-2.9.2.tar.gz -C /opt
  [root@master mfs]# cd /opt/fuse-2.9.2
  [root@client fuse-2.9.2]# ./configure
  [root@client fuse-2.9.2]# make && make install
      '//设置环境变量'
  [root@client fuse-2.9.2]# echo "export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig:$PKG_CONFIG_PATH" >> /etc/profile
  [root@client fuse-2.9.2]# source /etc/profile	'//使之不重启即可生效'
  
  

• 安装 MFS 客户端

  [root@client fuse-2.9.2]# cd ../moosefs-3.0.100/
  [root@client moosefs-3.0.100]# ./configure \
  > --prefix=/usr/local/mfs \
  > --with-default-user=mfs \
  > --with-default-group=mfs \
  > --disable-mfsmaster \
  > --disable-mfschunkserver \
  > --enable-mfsmount
  [root@client moosefs-3.0.100]# make && make install
  

• 挂载 MFS 文件系统

  [root@client moosefs-3.0.100]# cd
  [root@client ~]# mkdir /opt/mfs	'//创建挂载点'
  [root@client ~]# modprobe fuse	'//加载fuse模块到内核'
  [root@client ~]# /usr/local/mfs/bin/mfsmount /opt/mfs -H 192.168.233.131	'//指向master服务器地址'
  mfsmaster accepted connection with parameters: read-write,restricted_ip,admin ; root mapped to root:root
  [root@client ~]# df -hT
  文件系统                类型      容量  已用  可用 已用% 挂载点
  。。。省略内容
  192.168.233.131:9421    fuse.mfs   60G   13G   48G   21% /opt/mfs	'//挂载成功'
  
  

• MFS优化操作

  '//MFS 在客户端安装完毕后， 会生成/usr/local/mfs/bin/目录， 在这个目录下有很多命令是用户所需要的。 为了方便使用这些命令，将/usr/local/mfs/bin 加入到环境变量中'
  [root@client ~]# echo "export PATH=/usr/local/mfs/bin:$PATH" >> /etc/profile
  [root@client ~]# source /etc/profile
  '//mfsgetgoal 命令用来查询文件被复制的份数， 利用-r 命令可以对整个目录进行递归，goal 是指文件被复制的份数'
  [root@client ~]# mfsgetgoal -r /opt/mfs
  /opt/mfs:
   directories with goal          2 :          1
  
  '//命令 mfsgetgoal 用来设置文件被复制的份数， 生产环境 Chunk Server 节点数量应至少大于 2， 文件副本数小于等于 Chunk Server 服务器的数量'
  [root@client ~]# mfssetgoal -r 3 /opt/mfs/
  /opt/mfs/:
   inodes with goal changed:                       1
   inodes with goal not changed:                   0
   inodes with permission denied:                  0
  
  '//创建文件测试一下'
  [root@client ~]# cd /opt/mfs
  [root@client mfs]# touch aaa.txt
  [root@client mfs]# mfsgetgoal aaa.txt
  aaa.txt: 3
  
  

2.4.5：创建 MFS 监控

• master服务器启动监控程序

  [root@master ~]# /usr/local/mfs/sbin/mfscgiserv
  

• mfscgiserv是用python编写的一个web服务器，其监听端口是9425，可以在masster server 上通过 /usr/local/mfs/sbin/mfscgiserv来启动，用户利用浏览器就可以完全监控所有客户挂接、Chunk server、Master server等。

2.4.6：访问测试

• 宿主机浏览器打开http://192.168.233.131:9425
• 
• 宿主机浏览器打开http://192.168.233.131:9425/mfs.cgi?masterhost=master ，注意主机名
• 
• 其中各部分的含义如下：
  • Info 部分： 显示了 MFS 的基本信息。
  • Servers 部分： 列出现有 Chunk Server。
  • Disks 部分： 列出现有 Chunk Server 硬盘信息。
  • Exports 部分： 列出可被挂载的目录。
  • Mounts 部分： 列出被挂载的目录。
  • Operations 部分： 显示正在执行的操作。
  • Resources 部分： 列出当前存储信息。
  • Quitas 部分： 列出当前配额信息。
  • Master charts 部分： 显示 Master Server 的操作情况， 读、 写、 删除等操作。
  • Server charts 部分： 显示 Chunk Server 的操作情况、 数据传输率及系统状态。

三：学习 MFS 维护及灾难恢复

3.1：MFS 集群的启动与停止

• MFS 集群启动的顺序如下
  • （1） 启动 mfsmaster 进程。
  • （2） 启动所有的 mfschunkserver 进程。
  • （3） 启动 mfsmetalogger 进程（如果配置了 mfsmetalogger）。
  • （4） 在所有的客户端挂载 MFS 文件系统。
• MFS 集群停止的顺序如下。
  • （1） 在所有的客户端卸载 MFS 文件系统。
  • （2） 用 mfschunkserver stop 命令停止 chunkserver 进程。
  • （3） 用 mfsmetalogger stop 命令停止 metalogger 进程。
  • （4） 用 mfsmaster stop 命令停止 master 进程

3.2：MFS 灾难恢复

• 整个 MFS 体系中， 直接断电只有 Master 有可能无法启动， 可以在 master 上使用命令 /usr/local/mfs/sbin/mfsmaster -a修复

• MFS 元数据通常有两部分的数据， 分别如下：

  • 1、主要元数据文件 metadata.mfs， 当 mfsmaster 运行时会被命名为 metadata.mfs.back。

  • 2、元数据改变日志 changelog.*.mfs， 存储了过去的 N 小时的文件改变（N 的数值是由
    BACK_LOGS 参数设置的， 参数的设置在 mfschunkserver.cfg 配置文件中）。

  • 3、在 Master 发生故障时， 可以从 MetaLogger 中恢复 Master， 步骤如下。

  • 4、安装一台 mfsmaster， 利用同样的配置来配置这台 mfsmaster。

  • 5、将 metalogger 上 /usr/local/mfs/var/mfs/目录下的文件复制到 master 相应的目录中
    [root@master ~]#scp [email protected]:/usr/local/mfs/var/mfs/* /usr/local/mfs/var/mfs/

• 利用 mfsmetarestore 命令合并元数据changelogs

  • [root@master ~]#/usr/local/mfs/sbin/mfsmaster -a
  • 如果是全新安装的 Master， 恢复数据后， 要更改 metalogger 和 chunkserver 配置MASTER_HOST 的 IP， 客户端也需要重新挂载

3.3：灾难测试，恢复测试及其他测试参考资料

• 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, the entire mfs system, directly off only master may fail to start.

  • -使用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 maintained: chunker block (of chunks are) capable of autonomous replication or deleted

  • -对一个目录设定“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 repair: 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修复
    [root@localhost 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 space

  • -每一个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 snapshot

  • -可以快照任何一个文件或目录，语法：mfsmakesnapshot src dst
    -但是src和dst必须都属于mfs体系，即不能mfs体系中的文件快照到其他文件系统。
    Mfsappendchunks：追加chunks到一个文件
     
    snapshot测试：
    a、对一个文件做snapshot后，查看两个文件的块，是同一个块。把原文件删除，原文件删除后（回收站中最初可以看到，但一段时间后，回收站中就彻底删除了），snapshot文件仍然存在，并且可以访问。使用mfsfileinfo查看，发现仍然是原来的块。
    b、对一个文件做snapshot后，查看两个文件的块，是同一个块。把原文件修改后，发现原文件使用的块名变了，即使用的是一个新块。而snapshot文件仍然使用原来的块。
     
    

• 9, trash trash bin

  • -设置文件或目录的删除时间。一个删除的文件能够存放在“ 垃圾箱”中的时间称为隔离时间， 这个时间可以用mfsgettrashtime 命令来查看，用mfssettrashtime 命令来设置。单位为秒。
    -单独安装或挂载MFSMETA 文件系统（mfsmount -m mountpoint），它包含目录/ trash (包含仍然可以被还原的删除文件的信息)和/ trash/undel (用于获取文件)。
    -把删除的文件，移到/ trash/undel下，就可以恢复此文件。
    -在MFSMETA 的目录里，除了trash 和trash/undel 两个目录，还有第三个目录reserved，该目录内有已经删除的文件，但却被其他用户一直打开着。在用户关闭了这些被打开的文件后，reserved 目录中的文件将被删除，文件的数据也将被立即删除。此目录不能进行操作。
    
    

• 10, file descriptor

  • -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，客户端的各种操作等。