FastDFS－开源分布式文件系统

happy_fish100

FastDFS是一个开源的分布式文件集群，纯C语言编写。她对文件进行管理，功能包括：文件存储、文件同步、文件访问（文件上传、文件下载）等，解决了大容量存储和负载均衡的问题。特别适合以文件为载体的在线服务，如相册网站、视频网站等等。

详情请参阅：http://linux.chinaunix.net/bbs/forum-75-1.html
Google code项目网址：http://code.google.com/p/fastdfs/

q1208c

不知道跟CFS比有啥优势？

happy_fish100

请问CFS的全称是什么？我在google没有搜索到分布式文件系统相关的内容

q1208c

原帖由 happy_fish100 于 2008-7-16 17:25 发表
请问CFS的全称是什么？我在google没有搜索到分布式文件系统相关的内容

ClusterFS 这个是公司名， 现在被Sun收购了。
项目名叫 lustre ，目前的最新版本是1.6.x 小号我不记得了。

happy_fish100

我大致了解了一下lustre，感觉FastDFS和lustre一些思路比较类似，但也看出了一些差别。继续深入了解下去，相信这两个系统的差别会更多。
总体的差别，感觉lustre做得更底层一些，使用起来相对也比较复杂；FastDFS比较轻量级，使用和配置都相对比较简单。

FastDFS的一个设计目标是尽量降低运维成本，比如增加存储服务器时，系统会自动复制该卷（或组）中已有的文件。
FastDFS设计时借鉴了mogileFS的一些思想，比mogileFS更易维护和使用，和mogileFS相比，主要的特点摘录如下：
1. FastDFS完善程度较高，不需要二次开发即可直接使用；
2. 和MogileFs相比，FastDFS裁减了跟踪用的数据库，只有两个角色：tracker和storage。FastDFS的架构既简化了系统，同时也消除了性能瓶颈；
3. 在系统中增加任何角色的服务器都很容易：增加tracker服务器时，只需要修改storage和client的配置文件（增加一行tracker配置）；增加storage服务器时，通常不需要修改任何配置文件，系统会自动将该卷中已有文件复制到该服务器；
4. 直接使用socket通信方式，相对于MogileFS的HTTP方式，效率更高。

feiyueheu

好东西啊.我现在就用一个BSD和WIN联在一起.

ppxiaobai

都可以部署在什么操作系统上？

happy_fish100

目前在Linux和FreeBSD下测试通过，不支持windows。

nntp

有点意思，首先支持楼主的技术精神。

我有些问题,希望可以得到你的答案.

1. FastDFS 和MogilieFS的代码级差别, 我看到你提到了借鉴，我想知道你是 base upon MoglieFS,还是build from scratch? 如果是base upon, 主要修正/改进了 MoglieFS的那些设计想法?

2. Lustre本身也不是一个"重/厚"分布式文件系统，你看到的复杂，是因为Lustre被广泛应用在大量的高容量hpc 项目中，经过多年的进化，你看到的lustre部分比较复杂的地方，都是有道理的。n年前的lustre也是很简单的。 所以我想知道，从设计思路上，lustre面向对象的存储设计思路和FastDFS所采用的存储设计的差异?

3. 我想知道FastDFS是否对于海量小文件的密集更新有所开拓? 文件尺寸在200k以下, 单位更新密度在8000个/分钟的规模. 我看到你提到FastDFS适合网站类应用，很多网站在内容更新上，都会产生大量的海量小文件密集更新操作，比如C2C的在线交易中的产品照片和缩略照片等.

4. 我想知道FastDFS的健壮性,整个FastDFS集群搭建起来后，是否有规模尺寸较小的集群方面的可用性样例测试?

5. 我看到FastDFS用了GPLv3, 我想知道为什么不是v2?

6. FastDFS的社区开发人员目前有多少？参与和协作政策的管理是怎么样的?

7. 还有两个兼容性的问题: a)对IA64平台的支持?  b)是否对AMD64/EM64T分别有优化，特别是multicore的硬件环境.

谢谢

happy_fish100

一下提了这么几个问题，看来你对分布式存储这块挺有研究的。

>>1. FastDFS 和MogilieFS的代码级差别, 我看到你提到了借鉴，我想知道你是 base upon MoglieFS,还是build from scratch? 如果是base upon, 主要修正/改进了 MoglieFS的那些设计想法?
只是借鉴了MogileFS一些设计思想，并没有采用或借鉴MogileFS的代码。
详细说明请参阅http://www.csource.org/上FastDFS和MogileFS相关文章


>>2. Lustre本身也不是一个"重/厚"分布式文件系统，你看到的复杂，是因为Lustre被广泛应用在大量的高容量hpc 项目中，经过多年的进化，你看到的lustre部分比较复杂的地方，都是有道理的。n年前的lustre也是很简单的。 所以我想知道，从设计思路上，lustre面向对象的存储设计思路和FastDFS所采用的存储设计的差异?
FastDFS存储以文件为单位，目前的定位主要是解决大容量存储和高并发访问的问题。比较适合相册和视频等多媒体文件的存储和访问。


>>3. 我想知道FastDFS是否对于海量小文件的密集更新有所开拓? 文件尺寸在200k以下, 单位更新密度在8000个/分钟的规模. 我看到你提到FastDFS适合网站类应用，很多网站在内容更新上，都会产生大量的海量小文件密集更新操作，比如C2C的在线交易中的产品照片和缩略照片等.

考虑到性能和系统的简洁性，目前仅支持文件上传和下载，不支持更改文件内容。其中meta data暂时还不能修改，即将支持对meta data的修改。


>>4. 我想知道FastDFS的健壮性,整个FastDFS集群搭建起来后，是否有规模尺寸较小的集群方面的可用性样例测试?
目前我对FastDFS用几台服务器只进行了小规模的测试，系统运行平稳，没有发现任何问题。


>>5. 我看到FastDFS用了GPLv3, 我想知道为什么不是v2?
GPL v3相对v2更完善一些，采用GPL何种版本并不妨碍软件的自由分发

>>6. FastDFS的社区开发人员目前有多少？参与和协作政策的管理是怎么样的?
目前就我一个人，推出第一个版本还不到两周时间。如果有人愿意加入一起开发，我是非常欢迎的。

>>7. 还有两个兼容性的问题: a)对IA64平台的支持?  b)是否对AMD64/EM64T分别有优化，特别是multicore的硬件环境.

虽然没有做过这方面的测试，我相信运行在64位平台上应该没有问题。在64位机器上编译后运行也不会有问题，64位机器和32位机器混用应该也是可以的。FastDFS采用了标准C和标准的系统调用，不会涉及到CPU或指令级别的优化。