在像 MooseFS 或 XtreemFS 這樣的分佈式文件系統中，單個節點應該公開“原始”儲存還是 LVM 儲存？
在準備基礎架構以利用MooseFS或XtreemFS等分佈式儲存系統時，各個節點應如何將儲存呈現給環境的其餘部分？
將分區呈現在物理硬體附近是否更好，或者各個節點是否應該呈現邏輯捲和/或卷組？
在之前的問題“有沒有辦法通過 NFS 做類似 LVM 的事情？ ”，我通過 VMware 的中介使用像GlusterFS這樣的分佈式系統獲得了類似的結果。
對於分佈式文件系統，如何最好地處理這種情況？該方法是否因選擇的分佈式文件系統而異？
似乎有兩種通用方法（至少在 MooseFS 和 XtreemFS 世界中）：
一次開車
對於 MooseFS，最好的方法是使用一個 HDD 作為連接到 chunkserver 的一個 XFS 分區。我們不建議使用任何 RAID、LVM 配置。
為什麼？
首先是硬碟錯誤。如果您的硬碟驅動器開始變慢，則很難在 LVM 上找到它。在 MFS 上，您甚至可以從 MFS 主網站上快速找到它。第二件事：向 MooseFS 添加或刪除硬碟驅動器比添加或刪除 LVM 組更容易。只需將 HDD 添加到 chunkserver，格式化為 XFS，重新載入 chunkserver，您的實例就會有額外的空間。第三件事是 MoooseFS 有許多更好的排序算法可以將塊放置到許多硬碟上，因此所有硬碟驅動器都有平衡的流量 - LVM 沒有
一次成交量方法
XtreemFS OSD（以及其他服務）依賴於本地文件系統來儲存數據和元數據。因此，在具有多個磁碟的機器上，您有兩種可能性。首先，您可以將一台機器上的多個磁碟組合成一個文件系統，例如通過使用 RAID、LVM 或 ZFS 池。其次，每個磁碟（包括 SSD 等）都擁有自己的本地文件系統，並由自己的 XtreemFS OSD 服務導出。
這兩種可能性都有其優點和缺點，我不能給出一般性的建議。第一個選項在使用的 RAID 級別或可能附加的 SSD 記憶體方面帶來了靈活性。此外，維護和監控每台機器一個 OSD 程序可能比每個磁碟一個程序更容易。
每個本地磁碟使用一個 OSD 伺服器可能會帶來更好的性能。在執行快速 SSD 的 RAID 時，XtreemFS OSD 可能會成為瓶頸。您還可以通過多個網路介面在一台機器上分擔多個 OSD 的負載。對於複製的文件，您必須關心副本的放置，並避免將一個文件的多個副本放置在執行在同一硬體上的 OSD 上。您可能必須編寫自定義 OSD 選擇策略。XtreemFS 為此提供了一個介面。
哪個看起來更好
根據 XtreemFS 的響應，MooseFS 似乎可以從一次卷的方法中受益，但前提是您可以很好地緩解潛在的驅動器故障。
Drive-at-a-time 的好處是，在單個驅動器發生故障（這似乎是可能發生的最令人擔憂的物理錯誤）的情況下，MooseFS 的排序算法和恢復系統可以複製現在未複製的數據並“忽略“故障驅動器。
一次卷具有強制複製數據在不同伺服器上的好處 - 但不能保證均勻/水平的單個驅動器使用。