我读了一些类似的问题，但仍然对我的情况有些混淆。
我的网站允许用户上传大量的大图像（扫描书页）。 我的服务器将自动平铺和保存这些图像。 所以每个页面将成为10万个小的平铺器（每个图像是128px * 128px，占用2k空间）。 我有大约100GB的图像，现在他们已经填满了所有的inode表。
这是我的理解，如果我错了，请纠正我。
MySQL blob
好处：不需要担心inode /目录结构。
不足之处：图片放慢，可能会减慢整个数据库的速度
文件系统
好处：更快的图像服务
缺点：备份速度慢，额外的目录devise，需要大的inode大小（这也意味着我必须重新格式化我的服务器磁盘）
mongoDB BinData与base64（我不熟悉这个，但它似乎是一个不错的select）
亚马逊S3
好处：他们照顾一切
缺点：需要赚钱，并失去对这些图像的完全控制。
（更新：我可能不允许使用第三方提供商，但是我仍然会在这里生活，因为对于其他人来说这可能是一个很好的解决scheme，根据@Niels的build议。）
其他魔术很棒的解决
所以我想知道哪种情况最好，为什么。 感谢帮助
我肯定会去S3，除非你有成千上万的非常活跃的用户…即使你做了一些捐款或广告应该支付的成本。 与您自己的服务器相比，S3存储真的很便宜。 存储100GB的数据将花费你每月9美元，在高冗余水平。 这意味着对至less4个存储位置进行镜像，交易保证的耐用性为99.9999％，这样的成本在3年内不会真正地为您购买单台服务器。 stream量可能是昂贵的，但是你要支付每个托pipe提供商，所以没有真正的区别，除非你得到大数字。
S3在内部是一个高度优化的string字典，因此能够存储数百万甚至数十亿的相关文件。
诚实地说，让自己免受挫折，并以一个小小的代价随着所有的备份，冗余和服务器pipe理问题而消失，然后专注于保持周围的网站性能。 太多乐趣了。
另外，如果带宽使用真的是天文数字，请考虑使用您的networking服务器作为“边缘”服务器。 在大多数海量存储场景中，有99％的时间需要1％的内容（请考虑Facebook照片）。 一些脚本可以在本地镜像1GB的最近请求的图像，并在上次访问时刷新，应该很容易做到，并且可以将S3带宽成本保持在免费级别内。
据我所知，没有办法调整现有文件系统上的inode数量。
如果可以重新创build文件系统，则可以使用-N选项为新FS指定更多的inode