我也觉得这个影响大，大量的小文件还是选用r*fs，当然你要考虑考虑它的作者入狱给你带来的影响~~

关键是这个系统以后还会维护、更新吗？

文件下载后直接保存在本地目录，设置文件时间和FTP的LIST信息一致，不允许其它程序删除，这个方案运行时发生inode被用光问题

??? 文件数目太多？ 如果这样， 你除了将文件保存在db里面 或者将多个文件合并起来，还有其他的解决方案吗？

不允许其它程序删除
这个业务里面有个特殊需求：那就是同步到本地的文件，有可能被另外的应用程序删除，也有可能原地不动，但绝不会被修改，

这个实现和要求页抵触了吧？

我用着感觉挺好。
100万文件肯定是会慢，可是自己写这样的程序就能保证比rsync快吗。

rsync肯定采用了某种中间机制，每次同步时并不会直接去读取源机器所有的文件，所以更新是非常快的。
我这里应用的情况是：大约6、7万个文件，占用9G多的空间，两台机器在同一个100M局域网，两边一致的情况下，同步一下1秒不到。此外，源端经常会新增5000个文件，这时候再同步，一般不到1分钟。

想问楼主几个问题：
两机之间是什么线路？局域网、互联网？
这个同步是主从式的吗？
这个同步操作频繁吗？
需要这个同步操作发生时，两机负载如何？
未更新的文件被重复下载了会如何？
源机上的文件分布如何？比如是否有多级目录等。

其实我觉得这个问题的本质不是“数据库与文件的选择”，而是功能实现的策略、角度问题。

已经进入了Linux内核了，也就意味着，如果没有更好的替代品，它就永生了！（当然Linux死了，它也可能会死）。

根本不用担心是否有人会去维护、更新，当有需要时，会有人去做的。

用并行吧!

如果一个文件夹下面有50万文件，rsync还能用吗？

真实系统是这样的
源FTP下面有不到2000个子目录，目录树一共就两层，根目录和一级子目录
文件数量在1亿左右
单个文件夹最大有100万个文件
如果能用rsync，我编这个扯淡程序干嘛?
用户那边有的是LINUX开发人员

这个是特定条件下的特定业务，我没办法改变用户的应用环境
源服务器是个有64G内存的小机，有阵列柜

楼主, 我从方案一中看不出inode被用光的原因, 能否解释下?