LVM 和 mdadm / dmraid 都在 Linux 上提供软件 RAID 功能。这几乎是一个后续帖子这个问题是2014年的。那时，@德罗伯特建议选择 mdadm 而不是 LVM raid，因为它很成熟 - 但那是 4 年前的事了。我可以想象，从那时起事情就发生了变化。但我以前从未使用过 LVM raid，也找不到任何最近的经验。
那么 LVM raid 的状态如何？现在已经成熟了吗？是否有提到的缺陷@德罗伯特的帖子现已解决，还是仍然存在？关于什么
- 稳定，
- 特征（增长、缩小、转换），
- 修复和恢复，
- 社区支持，
- 表现
LVM raid 与 mdadm 相比？
我想知道人们是否真的使用它，或者每个人是否仍然坚持使用 mdadm。是否更建议在 mdadm 之上使用 LVM 进行逻辑卷管理，或者让 LVM 也管理 raid 也可以吗？即使您不希望需要逻辑卷管理的优势，使用 LVM raid 代替 mdadm 是否值得考虑？
我考虑在原始答案下添加评论，询问@德罗伯特更新他的帖子，但决定提出一个新问题。我想接触其他成员，获得新的体验，而不仅仅是把旧的帖子变成现在时。
答案1
我是一个团队中的资深人士，我们有多个环境（如果我没记错的话，现在大约有 5 个环境，但到年底将会获得更多环境）。
这些环境的重量从 8 到 25 台物理主机（通常在 CPU 和内存上已满载），每个主机上运行 50 到 400 个虚拟服务器。
存储始终位于光纤通道上，但结构交换机和磁盘阵列根据客户的不同而有很大差异（他们获得的交易、与他们拥有的存储公司的关系等）。
每个环境跨越 2 个数据中心，这些数据中心通过 DWDM 互连（使两个 DC 网络（ip 和 fc）显示为一个）。当然，网络会被 VLAN 和 FC 分区分割成更小的部分。
我们拥有各种虚拟机管理程序，包括 vmware（运行起来很酷）、virsh 下的原始 qemu+kvm、在pacemaker 集群下运行的 virsh 下的 qemu+kvm 以及由 ovirt 协调的 virsh 下的 qemu+kvm。
我们使用虚拟机管理程序集群和虚拟机内集群。
最古老的环境已经有 10 多年的历史，但会周期性地进行翻新（如果你能想象的话，这是一件令人难以置信的苦差事）。
为什么要描述这一切？正如你所看到的，这样的动物园相当有活力。我很感激在过去近 4 年里每天都能看到所有这些技术的发挥作用（天哪，时间过得真快）。我不需要补充一点，在这样的环境中，通常有数千个 LVM 卷，并且在您工作期间您最终会接触到所有这些卷。
最旧的环境完全基于 LVM，我能说的是：它可以工作，直到它不起作用为止。
我对 LVM 的主要问题是，如果它做了一些愚蠢的事情，你就得靠你自己了。它经常发生在您最不期望（或者更确切地说需要它）和生产环境（不是开发，不是测试或预生产）中。
此外，命令非常巴洛克式，并且有点可逆，但仅限于当您开始在卷上泵送数据时。一旦发生这种情况并且您只有在之后才发现错误，您应该简单地刻录该卷并开始一个新的。它会更快，可能更健壮，而且你会犯更少的错误。
我见过几个奇怪的 LVM 错误，这些错误基本上意味着整个 LVM 设置的丢失。
最令人震惊的是新手管理员将 LVM 堆栈扩展了百分之几 Gig 的存储，这导致扩展的 LV 突然报告-4万亿的大小。卷的奇怪负大小使得无法运行 umount、fsck 或任何其他修复工具，并引入了其他问题。幸运的是，进入目录仍然有效，因此我们再次重建了整个虚拟机并使用 rsync 来传输（主要是只读）数据。然后数据团队进行了分析，他们没有发现任何数据丢失 - 所以可能只是空闲空间被某种方式弄乱了。但最终的结果是，LVM 导致了如此复杂的情况，并且锁定了卷，甚至连基本的数据恢复工具都无法运行。
原来的系统也丢失了，必须更换然后拆除。我和我们的架构师，我们对发出的命令进行了分析，这完全是按照书本完成的，所以我不确定那里发生了什么。
我们还有少量使用cling扩展的 LVM 镜像（以使 LV 子设备粘在物理层上正确的数据中心）。这确保了如果交叉直流链路断开，镜子将至少在一侧组装。我要说的是，您不想在半夜处理这些设置。
我们从来没有勇气使用 LVM 快照，尽管据说它们已经被修复了。网上有很多关于它们的恐怖故事，我不愿意尝试它们，特别是因为现在我们有工具可以完全避免这些问题。
关于正常使用，我对 LVM 和 Linux 文件系统整体状态的主要问题是它们无法检查自己的狗屎。
我还没有时间深入研究 LVM 镜像，但我仍然没有找到人或明确的书面确认，LVM 镜像是否真的计算块的校验和（任何校验和甚至 crc32 都会这样做）。那么即使我运行 LVM 镜像重新计算，它实际上在做什么？如果进度计数器达到 100% 并且不匹配计数器为 0，这是否意味着镜像之间的数据匹配，或者已完成完整校验和并且没有错误（这两者是完全不同的事情，对吧）？
我遇到的 LVM 的第二个问题更为间接：最常见的文件系统： 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、ext4没有xfs用户jfs数据的校验和 。这在上世纪 90 年代可能很酷，但现在却是一个大问题。现在我们更清楚了：您实际上并不关心用户数据元数据，因为您关心的是实际的用户数据内容。无论如何，存储有什么意义呢？想知道照片上次更改的时间，或者实际查看照片上的内容？
我注意到有一些计划至少添加基本的用户数据校验和xfs，但目前还没有。
为什么这有关系？在集群环境中，经常会发生围栏，有时这种围栏最终会导致石环。那么在一次事件之后，当集群最终稳定下来时，现在怎么能说数据没问题呢？
使用 LVM + FS 你根本做不到，因为没有办法。是的，与备份相比……我们就这样吧，对吧？
最后，LVM 很脆弱。特别是在被动/主动集群卷甚至集群 lvm 设置中，它需要您将哪些 lvm 部分构建根标记到 lvm.conf 中。否则，LVM 不知道哪些部分是集群的，哪些是它想要启动的根，因此它会将它们全部组装起来 - 这是集群中的一个大问题。为了解决这个问题，你需要确保这个 lvm.conf 的副本也被复制到 initrd 中（看看你的 dracut）。如果您不能确保所有这些，那么下次当两个（或更多）节点同时启动时，它们都会尝试激活相同的 lvm 卷 - 您可以想象那时的乐趣。
我已经记不清有多少次在新手管理员配置和组装集群后我必须修复这个问题（并且他们是由我专门指示的）。即使他们经常忘记写下的笔记，这也意味着这一步很困难。
这是一个非常好的滴答作响的炸弹，你可以留给你的同事来解决，因为通常它只在第一个击剑之后显示:)。
因此，在这些年里，我开始相信 LVM 应该消失——它达到了它的目的，但 ZFS 和 BTRFS 可以做它能做的一切，而且更好，甚至更多。
ZFS 和 BTRFS 都将所有池元数据直接存储在池中。没有 dracut 绑定 btrfs/zfs.confs，池与 init ramdisk 完全断开连接，因为它从一开始就应该如此。您可以在内核命令行中指定要使用的池上的 root。
最重要的是，出现任何故障后，您可以在 BTRFS 和 ZFS 上运行清理，并实际重新扫描您的存储以获取真实信息用户数据（！）错误。如果有的话，擦洗是最重要的杀手级功能，这也是您应该运行任何下一代 FS 的原因。通过清理，您实际上可以确信自己没有任何静默数据损坏。
第二件最重要的事情是，快照确实有效。总是。快照是COW系统的基本工作单元，是一切的关键，所以如果它不起作用，你就会遇到更大的问题。
最后，如果你处于“贫穷”的一方，那么 BTRFS 是一种可行的方法，因为它能够处理大量的数据。它可以分裂它们、缩小它们、重新平衡它们并对它们做许多其他奇怪的事情。您可以在 BTRFS 系统中与磁盘共舞，直到找到最佳状态。这是廉价 Linux 管理员（这意味着 90% 的 Linux 管理员）的终极梦想，他们买不起存储。或者谁喜欢重建存储 3 次，同时仍然访问相同的数据，直到找到最佳解决方案。
ZFS 在这方面的能力正在慢慢增强，但距离 BTRFS 的可延展性还很远。但 ZFS 的一件事是，与 BTRFS（有点像 Linux buggy）不同，ZFS 是强大的数据卡车（甚至是油轮）。
ZFS 已经完成了大量的测试，工具具有令人难以置信的完善，只需将其与 BTRFS 进行比较，您就会立即看到花了多少钱以及在哪里。提示：如果没有 root 访问权限，您甚至无法对 BTRFS 池运行查询命令，而使用 ZFS，您可以为每个 ZFS 操作拥有完整的访问控制列表，并且您可以将其委托给特定用户。
总而言之，根据我的预感，几年后 ZFS 将在功能对等方面慢慢与 BTRFS 匹敌，而我估计仅完成 20％ 的 BTRFS 将永远保持未完成状态，这在 Linux 世界中太常见了。
不过，两者中的任何一个都会为您节省大量 LVM 麻烦。