在像MooseFS或XtreemFS这样的分布式文件系统中，各个节点是否应该公开“原始”存储或LVM的存储？

看来有两种一般的方法（至less在MooseFS和XtreemFS世界中）：

一次开车

对于MooseFS，最好的办法是将一个HDD作为一个连接到chunkserver的XFS分区。 我们不build议使用任何RAID，LVMconfiguration。

为什么？
第一件事是硬盘错误。 如果你的硬盘开始慢下来，很难find一个它在LVM上。 在MFS上，您甚至可以从MFS主站点快速find它。 第二件事：添加或删除硬盘到MooseFS比添加或删除LVM组更容易。 只需将硬盘添加到chunkserver，格式化为XFS，重新加载chunkserver，并且在您的实例上有额外的空间。 第三件事是，MoooseFS有很多更好的sortingalgorithm，把块放到很多硬盘上，所以所有的硬盘都有平衡的stream量 – LVM不会

一次一卷的方法

XtreemFS OSD（以及其他服务）依靠本地文件系统来存储数据和元数据。 因此，在具有多个磁盘的机器上，有两种可能性。 首先，您可以将一台计算机上的多个磁盘组合到单个文件系统，例如使用RAID，LVM或ZFS池。 其次，每个磁盘（包括SSD等）都拥有自己的本地文件系统，并由自己的XtreemFS OSD服务导出。

这两种可能性都有其优点和缺点，我不能提出一个普遍的build议。 第一个选项为使用的RAID级别或可能连接的SSD高速caching提供了灵活性。 此外，维护和监视每台机器的一个OSD进程可能比每个磁盘一个进程更容易。

每个本地磁盘使用一个OSD服务器可能会导致更好的性能。 在运行快速SSD的RAID时，XtreemFS OSD可能会成为瓶颈。 您也可以通过多个networking接口在一台机器上共享多个OSD的负载。 对于复制文件，您必须关心副本放置，并避免在同一硬件上运行的OSD上放置一个文件的多个副本。 您可能必须编写自定义的OSDselect策略。 XtreemFS为此提供了一个接口。

这似乎更好

基于XtreemFS的反应，似乎MooseFS可以从一次一次性的方法中受益，但前提是您能很好地缓解潜在的驱动器故障。

一次驱动有一个好处，即在发生单个驱动器故障（这似乎是最可能发生的物理错误）时，MooseFS的sortingalgorithm和恢复系统可以复制当前未复制的数据，并忽略“失败的驱动器。

每次卷具有强制复制数据位于不同服务器上的优势 – 但不能保证每个驱动器的使用均匀/级别。

^{_{这些答案来自MooseFS和XtreemFS各自的邮件列表 – 只有语法和可读性得到了改进; 链接到原始线程提供}}