无论是 'du -sh /data'或'find /data -type f'都非常慢，使用的是 ext4文件系统。
求推荐优化方法。
换reiserfs会不会好点

曾经 就被这个问题困扰过

印象中，没有哪个文件系统能吃得消这样整。
你这啥系统，设计方案有问题。

du -s 和 find 本来就是要便利文件的，数量多了自然慢
但是你的上层应用应该不会有经常这么做的需求吧

没尝试过，之后测试一下
用户上传的图片，有什么建议吗？吧500w个文件分散倒10000个子目录后，还是慢。。
du -s 和 find 只是极端情况

我的目录里分了二级目录，比如 xxxxxxxx/xxxxxxxx/xxx.jpg，大概100W左右文件，速度完全没有问题。
当然你说的du -s和find是全遍历，不可能快的，换任何方式存文件都不行。

存数据库嘛

你得用mongo gridfs

嗯，上数据库吧。
或者结构复杂点，比如文件还是散列到目录中，但同时存储一份信息到数据库。
这样可以满足 du -s 的需求，直接数据库 sum()，find 也是数据库记录查找。

淘宝的文件系统阿。专处理小文件

看看tfs http://code.taobao.org/p/tfs/wiki/deploy/

说的，淘宝的TFS应该可以解决这个问题
腾讯的也有TFS，但是不知道有没有开源

按前缀分n级目录就行啊

map reduce

存储最好上SSD，做raid-1哇，如果要备份啥的，要用上 LVM。这里讲的比较多，也许对你有帮助 http://lwn.net/Articles/400629/

为何不用又拍云或者七牛

目前我们方案也类似 :)
数据库的话，会很大，几个t吧。
tfs有点意思。
cdn用于分发文件，本地的存储还是要用的

其实云存储解决的就是这种问题，本地存个索引就行了

自己硬盘上没备份心里不太踏实。不过结合云存储的方案，近期会实践一下，云和本地都存上一份，数据库纪录一下对应关系～

对每个目录在当前创建一个索引文件,使用后台任务进行索引, 查找统计就直接查索引

数据库吧。