moo

mfs权威指南(moofs)分布式文件系统

一站式解决方案(部署，性能测试)

原文网址：/

#!/bin/tony

1.我在性能测试中间遇到些问题，因为我时间有限，所以希望大家一起来测试解决，群策群力。有什么问题请大家及时指出来，

因为我也处在一个不断摸索的阶段。

不多做介绍，具体细节请参考本版mfs实践文章/，或者

baidu,google关键字田逸。

3.希望大家能提供更好的存储/文件系统的测试模型，来一起完善本文档。（热烈欢迎大家奉献测试脚本，测试用例等）。

4.希望大家提供生产环境的实际案例，配置环境，脚本，监控机制等等。

5.希望熟悉代码的朋友去看看mfs内部实现的机制。

6.特别感谢田逸的文档/10037/263515。

7.特别感谢战友:tt，灵犀，流云风，hzqbbc在内对广大爱好者分享宝贵经验。

8.特别感谢存储专家-《大话存储》的作者：冬瓜头，在我进行性能测试的时候，对我进行的指导。

9.特别感谢战友：高性能架构，CUID:leo_ss_pku，制作更专业更精美的pdf版本：MooFS权威指

南.pdf(3.32MB,下载次数:3868)，大家也可以他的blog上浏览在线版本：/doc/

mfs优势：

-(GPL)

0.通用文件系统，不需要修改上层应用就可以使用（那些需要专门api的dfs好麻烦哦！）。

1.可以在线扩容，体系架构可伸缩性极强。（官方的ca可以扩到70台了！）

2.部署简单。（sa们特别高兴，领导们特别happy！）

3.体系架构高可用，所有组件无单点故障。（您还等什么？）

4.文件对象高可用，可设置任意的文件冗余程度（提供比raid1+0更高的冗余级别），而

绝对不会影响读或者写的性能，只会加速哦！）

5.提供Windows回收站的功能.（不怕误操作了，提供类似oralce的闪回等高级dbms

的即时回滚特性，oralce这些特性可是收费的哦！）

6.提供类似Java语言的GC（垃圾回收）.

7.提供netapp，emc，ibm等商业存储的snapshot特性。

filesystem的一个c实现。（google在前面开路哦！）

9.提供webgui监控接口。

10.提高随机读或写的效率（有待进一步证明）。

11.提高海量小文件的读写效率（有待进一步证明）。

可能的瓶颈：

本身的性能瓶颈。（不太恰当的比方：类似mysql主从复制，从的可以扩展，主的

不容易扩展）。（战友：hzqbbc）

短期对策：按业务切分

1.体系架构存储文件总数的可遇见的上限。

（mfs把文件系统的结构缓存到master的内存中，个人认为文件越多，master的内存

消耗越大，8g对应2500kw的文件数，2亿文件就得64GB内存）。（战友：hzqbbc）

短期对策：按业务切分

2.单点故障解决方案的健壮性。（战友：tt,hzqbbc）

架构图

——————————————————

index

ter

nkrver

ent

4.系统管理

5.性能测试

6.参考文献

6.1测试数据

测试模型1

测试模型2

7.感谢

8.附录

9.实际操作案例

10.生产环境案例

监控

12.官方关于1.6.x版本的介绍(中文翻译：QQ群战友Cuatre)

官方英文FAQ（TC版）（提供者：QQ群战友灵犀）

ter热备方案

ios监控程序（提供者：QQ群战友流云风）

————————————————

环境：

master1台

chunkrver3台

client1台

os：

centos5.3x64

1mfsmaster

1.1安装mfsmaster

wget/project/moofs/moofs/1.6.11/mfs-1.6.

cdmfs-1.6.11

uraddmfs-s/sbin/nologin

./configure--prefix=/usr/local/mfs--with-default-ur=mfs

--with-default-group=mfs

make

makeinstall

cd/usr/local/mfs/etc/

cd..

cdvar/

mfs/

/usr/local/mfs/sbin/mfsmasterstart

psaxu|grepmfsmaster

lsof-i

tail-f/var/log/messages

1.2启动master服务

/usr/local/mfs/sbin/mfsmasterstart

workingdirectory:/usr/local/mfs/var/mfs

lockfilecreatedandlocked

initializingmfsmastermodules...

loadingssions...ok

ssionsfilehasbeenloaded

exportsfilehasbeenloaded

loadingmetadata...

createnewemptyfilesystemmetadatafilehasbeenloaded

nochartsdatafile-initializingemptycharts

master<->metaloggersmodule:listenon*:9419

master<->chunkrversmodule:listenon*:9420

mainmasterrvermodule:listenon*:9421

mfsmasterdaemoninitializedproperly

1.3.停止master服务

/usr/local/mfs/sbin/mfsmaster-s

1.4启动和停止webgui

启动：/usr/local/mfs/sbin/mfscgirv

停止：kill/usr/local/mfs/sbin/mfscgirv

1.5相关配置文件

192.168.28.0/

192.168.28.0/24/rw

nkrver

2.1从块设备创建本地文件系统

fdisk-l

3/dev/sdb

mkdir/data

chownmfs:mfs/data

mount-text3/dev/sdb/data

df-ah

/dev/sdb133G188M126G1%/data

2.2创建50G的loopdevice文件

df-ah

ddif=/dev/zeroof=/opt/=1Mcount=50000

lotup/dev/

3/dev/loop0

mkdir/data

chownmfs:mfs/data

mount-oloop/dev/loop0/data

df-ah

2.3安装chunkrver

wget/project/moofs/moofs/1.6.11/mfs-1.6.

cdmfs-1.6.11

uraddmfs-s/sbin/nologin

./configure--prefix=/usr/local/mfs--with-default-ur=mfs

--with-default-group=mfs

make

makeinstall

cd/usr/local/mfs/etc/

2.4启动chunkvrver

/usr/local/mfs/sbin/mfschunkrverstart

psaxu|grepmfs

tail-f/var/log/messages

2.5停止chunkver

/usr/local/mfs/sbin/mfschunkrverstop

ent

3.1安装fu

yuminstallkernel.x86_64kernel-devel.x86_64kernel-headers.x86_64

###rebootrver

yuminstallfu.x86_64fu-devel.x86_64fu-libs.x86_64

modprobefu

3.2安装mfsclient

wget/project/moofs/moofs/1.6.11/mfs-1.6.

cdmfs-1.6.11

uraddmfs-s/sbin/nologin

./configure--prefix=/usr/local/mfs--with-default-ur=mfs

--with-default-group=mfs--enable-mfsmount

make

makeinstall

3.3挂载文件系统

cd/mnt/

mkdirmfs

/usr/local/mfs/bin/mfsmount/mnt/mfs/-H192.168.28.242

mkdirmfsmeta

/usr/local/mfs/bin/mfsmount-m/mnt/mfsmeta/-H192.168.28.242

df-ah

4.系统管理

4.1管理命令

设置副本的份数，推荐3份

/usr/local/mfs/bin/mfstgoal-r3/mnt/mfs

查看某文件

/usr/local/mfs/bin/mfsgetgoal/mnt/mfs

查看目录信息

/usr/local/mfs/bin/mfsdirinfo-H/mnt/mfs

5.性能测试

5.1mfs

1.大文件(block=1Mbyte)

ddif=/dev/zeroof==1Mcount=5000

5242880000bytes(5.2GB)copied,48.8481conds,107MB/s

2.小文件(50byte*100w个*1client)(1000*1000)写入

real83m41.343s

ur4m17.993s

sys16m58.939s

列表

timefind./-typef|nl|tail

999999./0/1

1000000./0/0

real0m39.418s

ur0m0.721s

sys0m0.225s

删除

timerm-fr*

real6m35.273s

ur0m0.394s

sys0m23.546s

3.小文件(1Kbyte*100w个*100client){1000*1000)

写入（100client）

time../../p_touch_

real22m51.159s

ur4m42.850s

sys18m41.437s

列表（1client）

timefind./|nl|tail

real0m35.910s

ur0m0.628s

sys0m0.204s

删除（1client）

timerm-fr*

real6m36.530s

ur0m0.697s

sys0m21.682s

4.小文件（1kbyte*100w个*200client）{1000*1000)

time../../p_touch_

real27m56.656s

ur5m12.195s

sys20m52.079s

5.小文件（1kbyte*100w个*1000client）{1000*1000)

写入

time../../p_touch_

real30m30.336s

ur5m6.607s

sys21m

5.2本地磁盘

1.大文件(block=1Mbyte)

ddif=/dev/zeroof==1Mcount=5000

5242880000bytes(5.2GB)copied,58.7371conds,89.3MB/s

2.小文件(50byte*100w个*1client){1000*1000）

写入

time../touch_

real17m47.746s

ur4m54.068s

sys12m54.425s

列表

timefind./-typef|nl|tail

1000000./875/582

1000001./875/875

real0m9.120s

ur0m1.102s

sys0m0.726s

删除

timerm-fr*

real0m37.201s

ur0m0.432s

sys0m15.268s

5.3基准测试(第一次)

5.3.1随机读

5.3.2随机写

5.3.3顺序读

5.3.4顺序写

5.4基准测试（第2次）

5.4.1随机读

6.参考文献：

6.1文献

/10037/263515田逸

/gzs777

/官网

/测试工具

6.1测试数据

性能测试模型1

一个不知道名字的哥们的测试结果，我先贴出来，那哥们看到了密我.

小文件性能测试

二级100*100文件夹创建列表删除

单片15k.5

ext3

client单进程

real

0m0.762s

ur

0m0.048s

sys

0m0.261s

real

0m0.179s

ur

0m0.036s

sys

0m0.125s

real

0m0.492s

ur

0m0.036s

sys

0m0.456s

单片15k.5

ext3

client10并发进程

最长时间：

real

0m0.724s

ur

0m0.015s

sys

0m0.123s

最长时间：

real

0m0.057s

ur

0m0.006s

sys

0m0.025s

最长时间：

real

0m0.226s

ur

0m0.010s

sys

0m0.070s

6chunkrver

cache

client单进程

real

0m2.084s

ur

0m0.036s

sys

0m0.252s

real

0m4.964s

ur

0m0.043s

sys

0m0.615s

real

0m6.661s

ur

0m0.046s

sys

0m0.868s

6chunkrver

cache

client10并发进程

最长时间：

real

0m1.422s

ur

0m0.007s

sys

0m0.050s

最长时间：

real

0m2.022s

ur

0m0.008s

sys

0m0.108s

最长时间：

real

0m2.318s

ur

0m0.008s

sys

0m0.136s

二级1000*1000文件夹创建列表删除

单片15k.5

ext3

client单进程

real

11m37.531s

ur

0m4.363s

sys

0m37.362s

real

39m56.940s

ur

0m9.277s

sys

0m48.261s

real

41m57.803s

ur

0m10.453s

sys

3m11.808s

单片15k.5

ext3

client10并发进程

最长时间：

real

11m7.703s

ur

0m0.519s

sys

0m10.616s

最长时间：

real

39m30.678s

ur

0m1.031s

sys

0m4.962s

最长时间：

real

40m23.018s

ur

0m1.043s

sys

0m19.618s

6chunkrver

cache

client单进程

real

3m17.913s

ur

0m3.268s

sys

0m30.192s

real

11m56.645s

ur

0m3.810s

sys

1m10.387s

real

12m14.900s

ur

0m3.799s

sys

1m26.632s

6chunkrver

cache

client10并发进程

最长时间：

real

1m13.666s

ur

0m0.328s

sys

0m3.295s

最长时间：

real

4m31.761s

ur

0m0.531s

sys

0m10.235s

最长时间：

real

4m26.962s

ur

0m0.663s

sys

0m13.117s

三级100*100*100文件夹创建列表删除

单片15k.5

ext3

client单进程

real

9m51.331s

ur

0m4.036s

sys

0m32.597s

real

27m24.615s

ur

0m8.907s

sys

0m44.240s

real

28m17.194s

ur

0m10.644s

sys

1m34.998s

单片15k.5

ext3

client10进程

最长时间：

real

10m22.170s

ur

0m0.580s

sys

0m11.720s

最长时间：

real

33m32.386s

ur

0m1.127s

sys

0m5.280s

最长时间：

real

33m7.808s

ur

0m1.196s

sys

0m10.588s

6chunkrver

cache

client单进程

real

3m21.720s

ur

0m3.089s

sys

0m26.635s

real

9m26.535s

ur

0m3.901s

sys

1m11.756s

real

10m51.558s

ur

0m4.186s

sys

1m26.322s

6chunkrver

cache

client10并发进程

最长时间：

real

1m23.023s

ur

0m0.429s

sys

0m3.869s

最长时间：

real

4m10.617s

ur

0m0.643s

sys

0m11.588s

最长时间：

real

4m20.137s

ur

0m0.649s

sys

0m14.120s

6chunkrver最长时间：最长时间：最长时间：

cache

client50并发进程

real

1m26.388s

ur

0m0.074s

sys

0m0.679s

real

4m37.102s

ur

0m0.132s

sys

0m2.160s

real

4m37.392s

ur

0m0.132s

sys

0m2.755s

6chunkrver

cache

client100并发进程

最长时间：

real

1m29.338s

ur

0m0.062s

sys

0m0.363s

最长时间：

real

4m54.925s

ur

0m0.069s

sys

0m1.212s

最长时间：

real

4m35.845s

ur

0m0.068s

sys

0m1.640s

6chunkrver

cache

remote

client10并发进程

最长时间：

real

4m0.411s

ur

0m2.985s

sys

0m12.287s

最长时间：

real

8m31.351s

ur

0m4.223s

sys

0m29.800s

最长时间：

real

4m3.271s

ur

0m3.206s

sys

0m11.922s

三级100*100*100文件夹1234

变更日志/元数据大小55M左右60M左右60M左右60M左右

连续创建耗时

real

4m0.411s

ur

0m2.985s

sys

0m12.287s

real

4m12.309s

ur

0m3.039s

sys

0m12.899s

real

4m14.010s

ur

0m3.418s

sys

0m12.831s

real

4m14.214s

ur

0m3.247s

sys

0m12.871s

注：单盘多进程性能没有提升，因为都在iowait，甚至增加进程会消耗大量调度时间

MFS多进程时性能会提升，主要性能消耗集中在CPU系统时间。因此实际海量小文件性能要大大

性能测试模型2（感谢战友痞

子白提供）

两个Client同时dd测试

数据块1M文件大小20G

Client1写：68.4MB/s读：25.3MB/s

Client2写：67.5MB/s读：24.7MB/s

总吞吐：写：135.9MB/s读：50.0MB/s

写命令：ddif=/dev/zeroof=/mfs/test.1bs=1Mcount=20000

读命令：ddif=/mfs/test.1of=/dev/nullbs=1M

7.感谢

田逸

一个不知道名字的哥们（看到请联系我）

8.附录

8.11000*1000*1client脚本

#!/bin/bash

for((i=0;i<1000;i++))

do

mkdir${i}

cd${i}

for((j=0;j<1000;j++))

do

cp/mnt/test${j}

done

cd..

done

8.21000*1000*（100，200,1000client)脚本

#!/bin/bash

declare-fmake_1000_dir_file

cd`pwd`

functionmake_1000_dir_file{

start=${1}

stop=${2}

for((i=${start};i<${stop};i++))

do

mkdir${i}

for((j=0;j<1000;j++))

do

cp/mnt/test${i}/${j}

done

done

}

i=1

while[${i}-le1000]

do

((n=${i}+1))

make_1000_dir_file${i}$&

((i=${i}+1))

done

wait

9.实际操作案例

9.1默认的垃圾回收时间是86400，存在一种可能性是垃圾还没回收

完，你的存储容量就暴掉了。（案例提供者shinelian）

方案1：设置垃圾回收时间，积极监控存储容量。

经过测试，把垃圾回收时间设置300秒，完全可以正确回收容量。

方案2：手动周期性去删除metamfs里的trash目录下的文件（健壮性还有待测试，反正

删除后容量是回收了，不晓得有没有什么后遗症。）

经过测试，貌似没后遗症，有后遗症的同学请在里面联系我。

9.2mfs1.6.x的UrGuides和FAQ，并和灵犀沟通对文档

中不理解的地方，就理解不一致的地方达成一致。MFS1.6.x比1.5.x

中有以下的变化：(特别感谢内网友流云风和灵犀)

（1）修复1.5.x中在大批量操作时打开文件过多的bug。这个错误也在我们此次测试

的时候遇到，报的错误说是打开的文件过多，造成chunkerrver的链接错误。虽然后来

的测试中一直想模拟出来这个问题，但是一直无法模拟出来。在1.6.x中解决此问题，就

解决了很大的问题。

（2）新增加了masterlogger服务器。这是在1.5.x中所没有的，就是做了master

服务器的冗余，进一步的加强的master服务器的稳定性。在mfs体系中master是要求

最稳定以及性能要求最高的，因此务必保证master的稳定。

（3）修改1.5.x中存在的对于坏块的修复功能。在mfs1.5.x中遇到chunker坏块

校验，错误比较多的是很往往导致master将出现坏块的chunker自动的剔除出去的情况，

此次增加了对坏块的修复功能，很方便的进行修复，简化对坏块的处理功能。

（4）对metadata和changelog的新认识。之前认为changelog记录的是文件的

操作，定期的像数据库的日志一样归档到metadata中。发现上面的理解存在误区，真正

的是changelog中记录了对文件的操作，metadata记录文件的大小和位置。因此

metadata是比较重要的，在进行修复的过程中是采用metadata和最后一次的

changelog进行修复的。

（5）MFS文档中明确指出对于内存和磁盘大小的要求。【Inourenvironment(ca.

500TiB,25millionfiles,2millionfoldersdistributedon26millionchunkson70

machines)theusageofchunkrverCPU(byconstantfiletransfer)isabout

15-20%andchunkrverRAMusuallyconsumesabout100MiB(independentof

amountofdata).

Themasterrverconsumesabout30%ofCPU(ca.1500operationsper

cond)ddependsonamountofoperationsandRAMon

numberoffilesandfolders.】

（6）指出了在测试的过程中多个chunker并不影响写的速度，但是能加快读的速度。

在原来的基础上增加一个chunker时，数据会自动同步到新增的chunker上以达到数据的

平衡和均衡。

9.3mfs1.5.x数据恢复实例（案例分享：QQ群战友Xufeng）

其实很简单，就是mfsrestore,然后启动服务的时候，并有任何提示信息，进

程启不来,其实是配置文件放PID的目录会被删掉，重建这个目录，然后赋予权限就可以了,

我已经做过1.5到1.6的升级，还可以.

详情见Xufengblog/iamacnhero/tag/moofs

10.生产环境案例（大家踊跃提供，不断更新中

~~~~~~）

田逸

11webgui监控

gui_(143.72KB,下载次数:85)

gui_(209.36KB,下载次数:86)

gui_master_(212.79KB,下载次数:84)

gui_(223.96KB,下载次数:83)

官方关于1.6.x的介绍翻译人(QQ群战友：Cuatre)

Viewonnewfeaturesofnextreleav1.6ofMooFileSystem

关于对MFS(MooFileSystem)下一个发布版本V1.6新特性的一些看法

WeareabouttoreleaanewversionofMooFSwhichwouldincludealarge

featuresaresosignificantthat

estbetafilesareintheGIT

repository.

我们将要发布MFS一个最新版本，该版本修复了大量的bug,同时也包含了大量的新特性。

这些新特性非常重要和有特色，我们决定在1.6版本进行发布。最新的beta文件你可以

GIT的知识库找得到。

Thekeynewfeatures/changesofMooFS1.6wouldinclude:

MooFS1.6的主要特性及变化包括：

General:

Removedduplicatesourcefiles.

移除了复制源文件

Stripwhitespaceattheendofconfigurationfilelines.

配置文件行的末尾将为空白

Chunkrver:

Chunkrver

Rewritteninmulti-threadedmodel.

重写了多线成模式

Addedperiodicalchunktestingfunctionality(HDD_TEST_FREQoption).

增加了定期chunk测试功能（HDD_TEST_FREQ选项）

New-voption(printsversionandexits).

新的-v选项（显示版本）

Master:

Added"noowner"objectsflag(causobjectstobelongtocurrentur).

增加了"noowner"对象标记（可以使对象属于当前用户）

Maintaining`mfsdirinfo`dataonline,soitdoesn'tneedtobecalculatedon

everyrequest.

保持„mfsdirinfo‟数据在线，这样就不需要求每一个请求都进行运算。

Filesystemaccessauthorizationsystem(e,

REJECT_OLD_CLIENTSoption)withro/rw,maproot,mapallandpassword

functionality.

文件系统访问认证系统（类似于NFS的文件，REJECT_OLD_CLIENTS

选项），有ro/rw,maproot,mapall及密码功能

New-voption(printsversionandexits).

新的-v选项（显示版本）

Mount:

Rewrittenoptionsparsinginmount-likeway,makingpossibletoustandard

FUSEmountutilities(emfsmount(manualfornewsyntax).Note:old

syntaxisnolongeracceptedandmountpointismandatorynow(thereisno

default).

重写选项将采用类似于挂载的解析方式，使用标准的FUSE挂载工具集将成为可能（参见

新的mfsmount(语法手册）。注：旧的语法现在将不再被支持，而设置挂载点则是必

须的。（非默认选项）

UpdatedforFUSE2.6+.

升级到FUSE2.6版本以上

Addedpassword,filedatacache,

defaultattributecacheanddirectoryentrycacheareenabled,filedatacache

andfileentrycachearedisabled.

增加了密码，文件数据缓存，属性缓存及目录项选项。默认情况下，属性缓存及目录项缓存

是开启的，而文件数据缓存和文件项输入缓存则是关闭的

opendir()nolongerreadsdirectorycontents-it'sdoneonfirstreaddir()now;

fixes"rm-r"onrecentLinux/glibc/coreutilscombo.

opendir()函数将不再读取目录内容-读取目录内容现在将由readdir()函数完成；修复了当

前Linux/glibc/coreutils组合中的„rm-r‟命令

Fixedmtimettingjustbeforeclo()(byflushingfileonmtimechange);fixes

mtimeprervingon"cp-p".

修复了在clo()前的mtime设置（在mtime变化的时候刷新文件）

AddedstatisticsaccessiblethroughMFSROOT/.statspudo-file.

增加了表示访问吞吐量的统计伪文件MFSROOT/.stats

Changedmasteraccessmethodformfstools(pudo-file

inforedirection);fixespossiblemfstoolsraceconditionand

allowstoumfstoolsonread-onlyfilesystem.

对于mfstools改变了主要的访问路径（直接）

Tools:

Unitscleanupinvaluesdisplay(exactvalues,IEC-60027/binaryprefixes,

SI/decimalprefixes);newoptions:-n,-h,-HandMFSHRFORMATenvironment

variable-refertomfstools(manualfordetails).

在单元值显示方面进行一致化（确切值，IEC-60027/二进制前缀，SI/十进制前缀）；新

的选项：-n,-h,-H以及可变的MFSHRFORMAT环境----详细参见mfstools(手册

mfsrgetgoal,mfsrtgoal,mfsrgettrashtime,mfsrttrashtimehavebeen

deprecatedinfavourofnew"-r"optionformfsgetgoal,mfstgoal,

mfsgettrashtime,mfsttrashtimetools.

我们推荐使用带新的“-r”选项的mfsgetgoal,mfstgoal,mfsgettrashtime,

mfsttrashtime工具，而不推荐mfsrgetgoal,mfsrtgoal,mfsrgettrashtime,

mfsrttrashtime工具。（注意前后命令是不一样的，看起来很类似）

mfssnapshotutilityreplacedbymfsappendchunks(directdescendantofold

utility)andmfsmakesnapshot(whichcreates"real"recursivesnapshotsand

behavessimilarto"cp-r".

mfssnapshot工具集取代了mfsappendchunks（老工具集的后续版本）和

mfsmakesnapshot（该工具能够创建“真”的递归快照，这个动作类似于执行“cp-r”）工

具

Newmfsfilerepairutility,whichallowspartialrecoveryoffilewithsomemissing

orbrokenchunks.

新的mfs文件修复工具集，该工具允许对部分丢失及损坏块的文件进行恢复

CGIscripts:

FirstpublicversionofCGIscriptsallowingtomonitorMFSinstallationfrom

WWWbrowr.

第一个允许从WWW浏览器监控MFS安装的CGI脚本发布版本

官方FAQ（TC版）

Whataveragewrite/readspeedscanweexpect?

Therawreading/writingspeedobviouslydependsmainlyontheperformanceof

theudharddiskdrivesandthenetworkcapacityanditstopologyandvariesfrom

terperformanceofharddrivesudandbetter

throughputofthenet,thehigherperformanceofthewholesystem.

Inourin-houcommodityrvers(whichadditionallymakelotsofextra

calculations)andsimplegigabyteEthernetnetworkonapetabyte-classinstallation

onLinux(Debian)withgoal=2wehavewritespeedsofabout20-30MiB/sandreads

of30-50MiB/llerblocksthewritespeeddecreas,butreadingisnotmuch

affected.

SimilarFreeBSDbadnetworkhasgotabitbetterwritesandworreads,giving

overallaslightlybetterperformance.

Doesthegoalttinginfluencewriting/readingspeeds?

Generallyspeaking,

itdoesn’lttingcaninfluencethereadingspeedonlyundercertain

mple,readingthesamefileatthesametimebymorethanone

clientwouldbefasterwhenthefilehasgoaltto2andnotgoal=1.

Butthesituationintherealworldwhenveralcomputersreadthesamefileatthe

samemomentisveryrare;therefore,thegoalttinghasratherlittleinfluenceon

thereadingspeeds.

Similarly,thewritingspeedisnotmuchaffectedbythegoaltting.

Howwellconcurrentreadoperationsaresupported?

Allreadprocessareparallel-thereisnoproblemwithconcurrentreadingofthe

samedatabyveralclientsatthesamemoment.

HowmuchCPU/RAMresourcesareud?

Inourenvironment(ca.500TiB,25millionfiles,2millionfoldersdistributedon26

millionchunkson70machines)theusageofchunkrverCPU(byconstantfile

transfer)isabout15-20%andchunkrverRAMusuallyconsumesabout100MiB

(independentofamountofdata).

Themasterrverconsumesabout30%ofCPU(ca.1500operationspercond)and

ddependsonamountofoperationsandRAMonnumberoffiles

andfolders.

Isitpossibletoadd/removechunkrversanddisksonfly?

Youcanadd/dthatitisnotwito

disconnectachunkrverifthereexistsachunkwithonlyonecopy(markedin

orangeintheCGImonitor).

Youcanalsodisconnect(change)narioforthis

operationwouldbe:

edisk(s)forremoval

tthechunkrverprocess

rthereplication(thereshouldbeno“undergoal”or“missing”chunks

markedinyellow,orangeorredinCGImonitor)

echunkrverprocess

entry(ies)ofthedisconnecteddisk(s)in''

echunkrvermachine

harddrive(s)

hemachine

hechunkrverprocess

Ifyouhavehotswapdisk(s)afterstep5youshouldfollowthe:

tdisk(s)

harddrive(s)

hechunkrverprocess

Ifyoufollowtheabovestepsworkofclientcomputerswouldbenotinterruptedand

thewholeoperationwouldnotbenoticedbyMooFSurs.

Myexperiencewithclusteredfilesystemsisthatmetadataoperationsarequite

youresolvethisproblem?

Wehavenoticedtheproblemwithslowmetadataoperationsandwedecided

why

metadatarverhasincreadmemoryrequirements.

Whendoingdf-honafilesystemtheresultsaredifferentfromwhatIwould

expecttakingintoaccountactualsizesofwrittenfiles.

Everychunkrverndsitsowndiskusageincreadby256MBforeachud

partition/hdd,

youhave3chunkrverswith7hddeach,yourdiskusagewillbeincreadby

3*7*256MB(about5GB).Ofcourit'snotimportantinreallife,whenyouhavefor

example150TBofhddspace.

diskxclusivelyforMooFSon

chunkrversdfwillshowcorrectdiskusage,butifyouhaveotherdataonyour

MooFSdisksdfwillcountyourownfilestoo.

IfyouwanttoeusageofyourMooFSfilesu'mfsdirinfo'command.

Dochunkrversandmetadatarverdotheirownchecksumming?

ghtitwouldbeCPU

adisabout4Bpera64KiBblockwhichis4KiB

pera64MiBchunk(pergoal).

WhatsortofsizingisrequiredfortheMasterrver?

ThemostimportantfactorisRAMofmfsmastermachine,asthefullfilesystem

sRAMmfsmastermachineneedssome

spaceonHDDformainmetadatafiletogetherwithincrementallogs.

Thesizeofthemetadatafileisdependentonthenumberoffiles(notontheirsizes).

Thesizeofincrementallogsdependsonthenumberofoperationsperhour,but

length(inhours)ofthisincrementallogisconfigurable.

lationof25millionfiles

requiresabout8GiBofRAMand25GiBspaceonHDD.

WhenIdeletefilesordirectoriestheMooFSsizedoesn’?

MooFSisnoterasingfilesimmediatelytoletyourevertthedeleteoperation.

Youcanconfigureforhowlongfilesarekeptintrashandemptythetrashmanually

(toreleathespace).Therearemoredetailshere:

/pages/#2[MB1]inction"Operationsspecific

forMooFS".

Inshort-thetimeofstoringadeletedfilecanbeverifiedby

themfsgettrashtimecommandandchangedwithmfsttrashtime.

WhenIaddedathirdrverasanextrachunkrveritlookedlikeitstarted

replicatingdatatothe3rdrvereventhoughthefilegoalwasstilltto2.

ageballanceruschunksindependently,soonefilecouldbe

redistributedacrossallofyourchunkrvers.

IsMooFS64bitcompatible?Yes!

CanImodifythechunksize?

Filedataisdividedintofragments(chunks)

d

thechunksizeonreal-worlddataanditwasaverygoodcompromibetween

numberofchunksandspeedofrebalancing/ifa

fileissmallerthan64MiBitoccupieslessspace.

Pleanotesystemswetakecareofenjoyfilesofsizewellexceeding100GBand

thereisnochunksizepenaltynoticeable.

HowdoIknowifafilehasbeensuccessfullywritteninMooFS?

Firstoff,let'sbrieflydiscussthewaythewritingprocessisdoneinfilesystemsand

lly,filesarewrittenthrougha

buffer(writecache)ult,executionofthe

"write"commanditlfonlytransfersthedatatoabuffer(cache),withnoactual

,aconfirmedexecutionofthe"write"commanddoesnot

lywiththecorrect

performanceofthe"fsync"(or"clo"commandthatalldatakeptinbuffers

(cache)roroccurswhilesuchbuffer-keptdataisbeing

written,itcouldreturnanincorrectstatusforthe"fsync"(oreven"clo",not

only"write"command.

Theproblemisthatavastmajorityofprogrammersdonottestthe"clo"

commandstatus(whichisgenerallyamistake,thoughaverycommonone).

Conquently,aprogramwritingdataonadiscmay"assume"thatthedatahas

beenwrittencorrectly,whileithasactuallyfailed.

AsfarasMooFSisconcerned–first,itswritebuffersarelargerthaninclassicfile

systems(anissueofefficiency);cond,writeerrorsmaybemorefrequentthanin

caofaclassicharddrive(thenetworknatureofMooFSprovokessome

additionalerror-inducingsituations).Asaconquence,theamountofdata

procesdduringexecutionofthe"clo"commandisoftensignificantandifan

erroroccurswhilethedataisbeingwritten,thiswillbereturnedinnootherway

thanasanerrorinexecutionofthe"clo"commandonly.

Hence,beforeexecuting"clo",itisrecommended(especiallywhenusingMooFS)

toperform"fsync"afterwritinginafileandthencheckthestatusof"fsync"and–

justinca–thestatusof"clo"aswell.

NOTE!When"stdio"isud,the"fflush"functiononlyexecutesthe"write"

command,socorrectexecutionof"fflush"isnotenoughgroundstobesurethatall

datahasbeenwrittensuccessfully–youshouldalsocheckthestatusof"fclo".

Onefrequentsituationinwhichtheaboveproblemmayoccurisredirectinga

standardoutputofaprogramtoafilein"shell".Bash(andmanyotherprograms)

doesnotcheckthestatusof"clo"executionandsothesyntaxofthe"application>

"typemaywrapupsuccessfullyin"shell",whileinfacttherehasbeen

anerrorinwritingthe""stronglyadvidtoavoidusingthe

ssary,youcancreateasimpleprogramreadingthestandard

inputandwritingeverythingtoachonfile(butwithanappropriatecheckwiththe

"fsync"command)andthenu"application|",where

"mysaver"isthenameofyourwritingprograminsteadof"application>

".

Pleanotethattheproblemdiscusdaboveisinnowayexceptionalanddoesnot

ffectanysystemof

files–cally

speaking,theaboverecommendationsshouldbefollowedatalltimes(alsoinca

ofclassicfilesystems).