我们刚刚开始在 RAID 阵列上使用 LVM，感觉它减慢了我们用于测试升级的快照反转操作。我们对整个 RAID 和 LVM 事情不太熟悉，所以也许这是不可能的。
所以现在，我们通过执行以下操作来创建快照：
- lvcreate -l 100%FREE -n data_snap -s 数据/数据
- 然后我们运行系统升级包
- lvconvert——合并'数据/数据快照'
实际上需要很长很长很长的时间才能恢复，因此目前效率的提高微乎其微。我相信这可能是由一些问题引起的，但我正在尝试使用这个问题来解决其中的一些问题：
- 快照卷与原始卷位于同一物理磁盘上
- 我们有一个活动的软件 raid，支持 RAID1 在 2 个设备 SDB 和 SDC 上形成 MD0
- 我们原来的设置占用了 100% 的 MD0 来创建 /storage，我们没有空间来创建快照，所以我还必须 lvreduce 我的数据/数据来腾出一些空间，并在快照合并回来后将其恢复到 100%VG
- 我们在初始设置中将 /var 移至此 RAID 阵列，因此我必须将其移出到 SDA，并将绑定从 MD0 的 /storage 挂载欺骗到 SDA 的 /var，这样我们就可以保留 docker 内容在 RAID 上，以限制对卷的更改
因此，我的选择似乎是找到一种方法来暂停通过 MD0 将 SDB 复制到 SDC。但我不知道该怎么做。这可能会为我省去很多麻烦，但我不确定。
有人可以启发我吗？
答案1
您可以考虑使用精简 LVM 池来存储快照，而不是滥用 MD。
厚 LVM 快照（即您正在执行的操作）效果不佳。它们在仅一层快照之后就变得非常慢，并且需要很长时间才能合并，就像您看到的那样。您还遇到了将整个 VG 分配给单个 LV 的问题，该 LV 必须先缩小才能进行快照，这非常低效。
使用精简 LVM 池，您可以创建能够分配超过 100% 的精简逻辑卷，这样即使并非所有块都分配给实际数据，您也可以轻松创建快照。但是，如果您在生产中使用精简池配置，您可能应该为快照保留一定比例的可用物理范围。您自己决定。
创建这些精简卷只需比创建厚逻辑卷多几个步骤。事实上，精简池实际上只是嵌套在堆栈中已有的逻辑卷中的一些额外元数据。
以下指南将帮助您创建这些卷： 创建精简逻辑卷
这将帮助您创建这些卷的快照： 创建精简卷快照