我考虑一个电子邮件存储。 这个存储系统运行在我自己的私有云（已经复制）上，然后我不在乎复制。
我正在考虑2个选项：
1 – 我将创build几个“磁盘”（云上的卷），并在多磁盘上创build一个Btrfs文件系统; 当文件系统满了，我会创build更多的“磁盘”，并将其添加到btrfs文件系统：
btrfs device add /dev/vdX /mnt btrfs filesystem balance /mnt 这个挂载点（/ mnt）将通过NFS公开，我的Dovecot服务器将挂载这个导出，并在其上存储电子邮件。
2-我将创build一些“磁盘”（云上的卷），并创build一个GlusterFS分布式卷横跨这些磁盘; 当文件系统满了，我会创build更多的“磁盘”，并添加新的“磁盘”（S）GlusterFS分布式卷，重新平衡它。 我的鸽舍会使用glusterfs-client挂载这个卷，并在其上存储邮件。
（重复：我不需要复制，因为我的“磁盘”，在私有云上的卷，复制发）
你认为哪个选项更好：
您必须考虑邮件服务器的I / O模式：尽可能快地读取/写入许多小文件。 当处理大量的客户，恕我直言，你的变种是真的不适合这个。
FS都不够快，我想GlusterFS的locking开销特别重要。 然后你用NFS添加另一个层，它有自己的开销。 而不是这个，我会尝试尽可能小的开销和快速的文件系统连接邮件存储。 通常这意味着尽可能直接连接到物理存储，但是由于您隐藏了像“私有云”这样的废话宾果术语背后的架构，我们不知道什么是可能的。
你可以尝试的一种方法是通过iSCSI将存储导出到邮件服务器，然后使用一个快速的许多小文件的FS，也许，如果真的很重要的话，可以使用LVM来轻松地在这个FS中增加空间额外的iSCSI卷的forms（这增加了一些开销）。
无论你尝试什么：你必须基准不同的变种，看看你是否得到所需的性能。
如果你需要从上面两个select一个，那么我认为NFS更可取。
由于OpenStack卷仍然从中央存储挂载，因此GlusterFS在您的设置中将其作为分布式文件系统的所有优点都放弃了。 它既不稳定也不更聪明，因为它应该关心分布式文件locking，而在单个服务器上完成NFSlocking。
我不确定将多个设备的存储结合起来是个不错的主意。 或者，您可以考虑跳过高水平的OpenStack卷服务function，并直接暴露存储 – 由NFS导出的格式化的LVM（/ ZFS / SAN）卷。 通过这种方式，您可以消除不必要的iSCSI级别，只要主存储空间足够，就可以根据需要增加邮件存储空间。