数据安全性

1、写一份即成功：从源storage写完文件至同步到组内其他storage的时间窗口内，一旦源storage出现故障，就可能导致用户数据丢失，而数据的丢失对存储系统来说通常是不可接受的。

2、缺乏自动化恢复机制：当storage的某块磁盘故障时，只能换存磁盘，然后手动恢复数据；由于按机器备份，似乎也不可能有自动化恢复机制，除非有预先准备好的热备磁盘，缺乏自动化恢复机制会增加系统运维工作。

3、数据恢复效率低：恢复数据时，只能从group内其他的storage读取，同时由于小文件的访问效率本身较低，按文件恢复的效率也会很低，低的恢复效率也就意味着数据处于不安全状态的时间更长。

4、缺乏多机房容灾支持：目前要做多机房容灾，只能额外做工具来将数据同步到备份的集群，无自动化机制。

5、存储空间利用率

单机存储的文件数受限于inode数量

每个文件对应一个storage本地文件系统的文件，平均每个文件会存在block_size/2的存储空间浪费。

文件合并存储能有效解决上述两个问题，但由于合并存储没有空间回收机制，删除文件的空间不保证一定能复用，也存在空间浪费的问题。

6、负载均衡

group机制本身可用来做负载均衡，但这只是一种静态的负载均衡机制，需要预先知道应用的访问特性；同时group机制也导致不可能在group之间迁移数据来做动态负载均衡。

7、其他：

1）不支持POSIX通用接口访问，通用性较低

2）对跨公网的文件同步，存在较大延迟，需要应用做相应的容错策略

3）同步机制不支持文件正确性校验，降低了系统的可用性

4）通过API下载，存在单点的性能瓶颈

8、最最重要的一项：

1、几乎没有人维护，官方200多个isuees，很多bug从2014年至今都无人解决。

2、社区极不活跃，只有2个参与开发的contributors。

3、源码几乎无注释，代码写法偏个人风格，可维护性较差。

基于这点考虑，除非公司有人能读懂fastdfs源码，能做二次开发，否则这么多bug和待改进项，确实让人不安心。

随便摘几个issues大家看看：

1. 部分storage节点文件缺失，访问时没有重定向到存在文件的storage节点；

2. recv data fail or response status != 0, errno: 22, error info: Invalid argument

3. file: tracker_proto.c, line: 48 response status 2 != 0

4. storage目录建立在映射盘上，导致free storage为负数，从而无法上传文件

5. 下载文件时偶发的会连接到没有该文件的Storage节点去下载

6. file: storage_nio.c, line: 436, send timeout 大并发情况下出现以上问题

7. 生产系统故障，文件同步失败导致无法上传问题
   

具体可以参考 对比 TFS，GFS，HBase等，比如：

http://blog.chinaunix.net/uid-20196318-id-4453266.html