我考虑使用电子邮件存储。此存储系统在我自己的私有云上运行（已复制），因此我无需关心复制。
我正在考虑两个选择：
1- 我将创建几个“磁盘”（云上的卷），并在多磁盘上创建一个 Btrfs 文件系统；当文件系统已满时，我将创建更多“磁盘”并通过以下方式将其添加到 btrfs 文件系统：
btrfs device add /dev/vdX /mnt
btrfs filesystem balance /mnt
该挂载点（/mnt）将通过 NFS 公开，我的 Dovecot 服务器将挂载此导出，并在其上存储电子邮件。
2- 我将创建几个“磁盘”（云上的卷），并在这些磁盘上创建一个 GlusterFS 分布式卷；当文件系统已满时，我将创建更多“磁盘”并向 GlusterFS 分布式卷添加新“磁盘”，然后重新平衡它。我的 Dovecote 将使用 glusterfs-client 安装此卷，并在其上存储电子邮件。
（重复：我不需要复制，因为我的“磁盘”，私有云上的卷，在后台复制）
您认为哪个选项更好：
- 性能？（很多小的读/写 I/O）
- 稳定的？
- 灵活的？
答案1
您必须考虑邮件服务器的 I/O 模式：读/写许多尽可能快地处理小文件。在我看来，当处理大量客户端时，您的两种变体确实不适合这样做。
这两种文件系统都不够快，我猜 GlusterFS 的锁定开销尤其大。然后你用 NFS 添加另一层，这本身就有开销。与其这样做，我不如尝试用尽可能小的开销和一个快速的文件系统连接邮件存储。通常这意味着尽可能直接连接到物理存储，但由于你将你的架构隐藏在“私有云”等胡说八道的宾果术语后面，我们不知道会发生什么。
您可以尝试的一种方法是通过 iSCSI 将存储导出到邮件服务器，然后使用可以快速处理许多小文件的 FS，如果它确实很重要，那么可以使用 LVM 以便能够以附加 iSCSI 卷的形式轻松地向该 FS 添加空间（这会增加一些开销）。
无论您尝试什么：您都必须对不同的变体进行基准测试，并查看是否获得所需的性能。
答案2
如果您需要从以上两者中选择一个，那么我认为 NFS 是更好的选择。
GlusterFS 在您的设置中失去了作为分布式文件系统的所有优势，因为 OpenStack 卷仍从中央存储安装。它既不更稳定也不更智能，因为它应该关注分布式文件锁定，而 NFS 锁定是在单个服务器上完成的。
我不确定将来自多个设备的存储组合起来是不是一个好主意。或者，您可以考虑跳过高级 OpenStack 卷服务功能并直接公开您的存储 - 由 NFS 导出的格式化 LVM(/ZFS/SAN) 卷。这样一来，您将消除不必要的 iSCSI 级别，并且只要主存储有足够的可用空间，您就可以根据需要增加邮件存储空间。