我正在考慮儲存電子郵件。這個儲存系統運行在我自己的私有雲上（已經複製），那麼我不關心複製。
我正在考慮兩個選擇：
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 模式：讀/寫許多盡可能快地處理小文件。恕我直言，在與大量客戶打交道時，您的兩種變體確實不適合這種情況。
這兩個 FS 都不夠快，而且我猜想 GlusterFS 的鎖定開銷尤其會很大。然後使用 NFS 新增另一層，該層有自己的開銷。相反，我會嘗試以盡可能小的開銷和快速的檔案系統來連接郵件儲存。通常這意味著盡可能直接連接到實體存儲，但由於您將架構隱藏在“私有雲”等廢話賓果術語後面，我們不知道會發生什麼。
您可以嘗試的一種方法是透過 iSCSI 將儲存空間匯出到郵件伺服器，然後使用具有許多小型檔案的快速 FS，如果確實很重要，則可以使用 LVM 以便能夠輕鬆地在郵件伺服器中向該 FS 新增空間。附加iSCSI 磁碟區的形式（這會增加一些開銷）。
不管你嘗試什麼：你必須對不同的變體進行基準測試，看看是否能獲得所需的性能。
答案2
如果您需要從以上兩者中選擇其一，那麼我認為 NFS 是更好的選擇。
由於 OpenStack 磁碟區仍然從中央儲存安裝，GlusterFS 在您的設定中失去了作為分散式檔案系統的所有優勢。它既不更穩定也不更智能，因為它應該關心分散式檔案鎖定，而 NFS 鎖定是在單一伺服器上完成的。
我不確定合併多個設備的儲存是個好主意。或者，您可以考慮跳過高級 OpenStack 磁碟區服務功能並直接公開您的儲存空間 - 由 NFS 匯出的格式化 LVM(/ZFS/SAN) 磁碟區。透過這種方式，您將消除不必要的 iSCSI 級別，並且只要主儲存有足夠的可用空間，就可以按需增加郵件儲存空間。