我正在构建一个电子邮件系统，并考虑一些支持在线调整大小、断电时安全且不限制每个目录的文件数量（或者至少每个目录可以容纳数百万个文件）的文件系统
我想知道哪种文件系统最适合这种情况。你能帮我吗？提前谢谢！
附言：我对我的电子邮件存储进行分层，如下所示：
第 3 层：drbd（/dev/drbd0）上的文件系统（XFS、JFS、Btrfs、Reiser4 等）
第 2 层：LVM2 逻辑卷上的 DRBD（双主模式）
第一层：物理卷上的 LVM2（/dev/sdc、/dev/sdd、...）
第 0 层：物理卷（sdc、sdd……）是硬件 RAID10（启用了“写缓存模式”）（每个“物理卷”实际上是 4 个 HDD）
还有一个问题：你觉得我的设计有什么问题吗？
编辑：我正在使用带有 3.2 内核的 Ubuntu 12.04 LTS。
答案1
多年来，XFS 一直是我可靠的主力。我所说的邮件系统正在顺利运行 Cyrus IMAP 服务器，该服务器拥有 50,000 多个帐户（高峰期接近 100,000 个帐户）和大约 300,000 个邮箱。邮件文件有数千万个。一切都运行顺利，服务器负载基本处于空闲状态。
但是……每个目录有几百万个文件？我们谈论的是哪种邮件系统？XFS 可能以某种方式处理这个问题，但没有文件系统是为这种行为而设计的。
答案2
我推荐的那个列表是 XFS。您没有提供 Linux 发行版信息，但假设是 CentOS 或 Red Hat，XFS 现在已经集成了。它是一个成熟的文件系统，提供在线碎片整理，并且可以动态增长（而不是缩小）。我很少听说 JFS... Reiser 是一场赌博，已经失去了巨大的市场份额...Btrfs 还不够成熟对此深信不疑。ext4 有什么问题吗？
另请参考这些帖子：
答案3
如果较低层都是冗余的并且得到适当的维护，则选择文件系统时唯一需要考虑的就是抽象文件系统的速度和可靠性（因为可以假设较低层的这种冗余不会造成任何物理破坏）。
对于这些要求，传统 ext3 仍然胜出（仅具有元数据日志记录）——XFS 在操作系统故障方面表现不佳，而 ext4 还不够成熟，无法完成这些任务——我过去曾遇到过 ext4 卷出现严重的 FS 错误，但没有任何合理的理由。
话虽如此，“每个目录数百万个文件”的要求从何而来？
电子邮件存储为 mbox 或 maildir（或者最近的 dbox）；这些都不需要每个目录有数百万个文件 - 事实上，远非如此：maildirs 每个目录保存一个逻辑邮箱文件夹，我不知道有谁每个文件夹有超过几千个文件。
mbox 每个邮箱都是一个巨大的文件，如此而已，根本不适合今天的电子邮件存储。
dbox 是该领域的新产品，在大多数情况下，其性能应该优于 mbox 和 maildirs，但同样，它不会在单个目录中存储“数百万个文件”。
答案4
您列出的一些设置与我工作的许多电子邮件系统相匹配。一个很大的例外是，由于 DRDB 引起的问题，我们一直在尽可能地慢慢撤出它。99.99% 的时间里，它是完美的，故障转移也运行良好，但那些时候它不只是会带来一大堆痛苦。
正如其他人所评论的那样，每个目录的邮件数量将要速度会大大减慢。我们通过提供自动归档解决方案解决了这个问题。从最基本的层面上讲，这是一个通过 imap 连接的脚本，然后使用 imap 将较旧的邮件移动到按日期分类的归档子文件夹中。对于大多数邮箱来说，这可以让内容保持相对干净但仍然井然有序。
对于文件系统的选择，调整参数会产生相当大的差异，具体取决于您选择的邮箱格式。对于 maildir，noatime 可以对某些客户端产生影响，尽管如今 Dovecot 之类的内置缓存抵消了这种优势。