（免责声明：这个问题和其他所有问题一样，都有“时间限制”，我现在只是指出这一点，而不是暗示它）
审查我们基础设施的一些基本决定的一部分再次是卷/存储管理。我在这里主要谈论本地存储（或提供服务器无法智能处理的块设备）。
通过查阅网络、博客和社区，我发现 BTRFS 基本上已经死了，希望之地还没有到来，更糟糕的是，我看不到该项目有任何整体进展。
ZFS 似乎拥有一个更大的社区，但是我仍然不能完全信任它在 Linux 上的稳定性。
LVM 为大多数人所熟知，但它也有自己的一系列问题（快照、RAID 的外部处理，...）
Ceph 是新生事物，但实际上它并不是一个没有大量粘合剂的存储管理。此外，该系统在复杂性方面相当庞大，最吸引人的卖点 (CephFS) 仍被标记为“尚未准备好投入生产”——但嘿，总得有人先尝试一下 :)
GlusterFS 看起来不错，但我们遇到了脑裂问题，所以我们的信任程度很低——考虑到
到目前为止，我对这个话题的立场是这样的。问题是：
在接下来的几年里，如果您今天选择，如果约束是 Linux，您将使用哪种存储管理？
我个人认为重要性的偏好如下：
- 强大的社区支持
- “易于”操作（经过相对较短的适应期后，标准任务应该很容易完成）
- 受到不同发行版的广泛支持（至少
.deb和.rpm可用的） - 本机内核支持（或现场管理员的低维护成本）
（距离我上次在这里发帖已经过去很久了，所以请把我转到一个更好的地方）
答案1
我主要使用 Linux 上的 ZFS 来满足我的生产存储需求，有多种形式。
我主要使用 RHEL/CentOS 之类的系统，并花了十年时间在服务器上配备 XFS 作为主要文件系统。2012 年 11 月，已发布的 XFS 发生了变化Red Hat 内核中的错误导致新的 XFS 安装不适合我的需求。大约在同一时间，Linux 上的 ZFS项目改进了其交付/安装流程。
我大胆尝试，利用原生 Linux ZFS 的可用性，将其作为在生产工作负载下运行的机会。我使用这个设置已经快一年了，对这个决定非常满意。我有大约 40 台使用 ZFS 数据卷的不同容量的 Linux 服务器。
主要优点...
- 压缩。
- L2ARC 读取缓存有助于加速我的一些应用程序。ZFS 缓存机制是更加智能比Linux VM子系统更强大。
- ZFS 是比 LVM 更灵活的卷管理器，并提供更大的灵活性。
- 数据完整性是无可匹敌的……
- 我已经搞定了ZFS 中有很多愚蠢的事情并且仍然没有丢失数据......
一些缺点...
- 我有几个深奥的 ZFS 配置这需要深入研究源代码或依靠开发者社区来全面理解/优化。示例：Fusion-io 上 Linux 上的 ZFS，或硬件 RAID 上的 ZFS zvols，顶部为 XFS。
- Solaris/Illumos/Nexenta-land 中的一些 ZFS 最佳实践不适用于 Linux 或违反直觉（例如 zvol 调整）。
至于其他人……
- LVM 被广泛使用，但并不是 ZFS 的直接竞争对手。
- BtrFS 从未达到其巅峰。
- Ceph 在某些圈子中占有一席之地，并得到一定的支持。不过，我可能不会将其作为直接附加存储平台。
- Gluster 也拥有社区和一定的影响力。但同样，它只适用于一小部分应用程序。