我需要一个方向，因为所有的博客/长椅似乎都是矛盾的。
在目录树上有很多小文件，与AB / CD / EF类似…两个尺寸组：G1：10-20 kB G2：100-500kB
我需要真正快速访问与nginx服务器。
删除或创build性能并不重要。 可能需要一分钟，我不会在意。 读取/访问必须快速< – > nginx。 文件在创build时被复制到不同的磁盘上，所以没有涉及到RAID。 只是商品。 dynamicinode创build或类似。 可靠性不是一个主要的问题，因为在3个不同的服务器上有重复。
我读XFS适合高性能邮件服务器与许多小文件涉及。 其他人说，XFS在处理小文件和EXT4更糟糕。
它在互联网上保持矛盾。
总的来说问题是inode分配。 大inode表浪费空间。 设置太弱，你注定要删除和重新创build分区（没办法发生）。
对我来说，这是一个陷阱，可以阻止我添加新的文件，即使空间仍然可用。 这就是为什么我想切换到别的东西。
而由于高度dynamic的性质和难以预测的文件数量，似乎我卡住了。 因此需要您的意见。
btrfs被认为没有生产准备。 其他人似乎（可靠性）
我应该在这种情况下使用什么FS？
它在互联网上保持矛盾。
但是你希望在这里得到一致的答案？
我所要做的唯一的具体build议就是忘记ZFS，除非你在Solaris上运行（这很有意义）。
除此之外，如何configuration磁盘，I / O调度程序以及为磁盘I / O提供备用内存比FS的select重要得多 – 但是您具体询问了FS。 但是，您并没有提供有关您的Resilience要求的大量信息：您的能力有多可靠？ 你需要快照function吗？
虽然我是Reiser的忠实粉丝，并在我的networking服务器上运行了好几年，但是我不会在新系统上使用它 – 它从来没有被用作Linux内核的一部分，并且开发正在逐渐消失。
所以在一个Linux机器上剩下的候选者是XFS，JFS，Ext4和BTRFS（也有NILFS–但是这又是一个利基工具，恕我直言，性能方面再次糟糕）。
如果您必须使用LVM（即使没有快照IME，也会有相当大的性能开销），那么确保最近有一个支持障碍的发行版，并在使用日志文件系统时启用障碍。
如果性能是您唯一的考虑因素，那么现在是时候开始基准testing了 – 我推荐使用Jens Axboe的fio来测量读/写性能 – 它可以configuration为模拟一些工作负载。
ZFS和XFS dynamic分配inode，以适应需要。 我不会赌ReiserFS。