今天升级 rhel 5 服务器后，我重新启动到新内核：curr=2.6.18-371.el5PAE prev=2.6.18-348.18.1.el5PAE。
在启动过程中，我看到一条消息，表明逻辑卷管理正在启动，然后几乎立即我看到了这个，并提供了一个救援 shell：
发现重复的 PV BPF...ayV：使用 /dev/sdc1 而不是 /dev/md3。
注意：/dev/sdc1 和 /dev/sdb1 是 raid1 阵列 /dev/md3 的成员。
由此，我假设 lvm2 软件认为 /dev/sdc1 和 /dev/md3 是具有相同 UUID 的 pv，并且 lvm2 软件选择忽略 /dev/md3 并使用 /dev/sdc1。
我关闭电源，拔下 sdc 的驱动器，然后重新启动。出乎意料的是，系统启动时我没有发现任何问题。当然，md3 被降级了。
我关机，插入拔下的驱动器，重新启动，系统重新启动，我没有发现任何问题。当然，md3 仍然降级，但发生了一些意想不到的事情。
有问题的逻辑卷内的文件系统已被挂载。
我执行了 pvdisplay，看到了同样的错误。当然，当我尝试将 sdc1 重新添加到 md3 时，它不允许我这样做，因为它正在被 lvm2 软件使用。
我卸载了文件系统并在 lv 设备路径上运行了 e2fsck。没有问题（但应该有问题）。
实际上有四个相关问题（抱歉）。假设 3 的答案是“是或有点”，那么 4 的答案就是我需要的。我问前两个是因为我假设我需要理解他们的答案才能理解后两个的答案。
如果逻辑卷最初是由 /dev/md3 而不是 /dev/sdc1 的 pv 组成，那么为什么文件系统正常？
/dev/sdc1 是否应该与 /dev/md3 不同，以防止逻辑卷与其中的物理卷保持一致？这可以通过问题 1 来回答。
我可以通过从 /dev/sdc1 中删除 pv 信息并将 /dev/sdc1 添加回 /dev/md3 来解决我的问题吗？
如果问题 3 的答案是肯定的，那么我该如何在不破坏逻辑卷及其文件系统的情况下进行操作？
一些历史：
我从未执行过“pvcreate /dev/sdc1”，所以我不知道为什么会发生这种情况。然而，/dev/sdc 最近确实让我很困扰，因为 smartmon (sp?) 会告诉我它无法读取智能数据，甚至无法看到设备。我将通过 (a) 重新启动、(b) 重新启动 + bios 挂起 + 关机 + 重置 sata 电缆 + 开机或顺序 b 但更换 sata 电缆而不是仅仅重新安装它来解决问题。
答案1
我不确定您是否问了您认为问的问题，但是 /dev/md3 与 /dev/sdb1 和 /dev/sdc1 相同，因为它是一个镜像集。
不，不应该。
不可以，这样会造成数据丢失。
不适用
/etc/lvm.conf您可以通过修改文件来更改过滤器以拒绝 sdb* 和 scd* 设备，重新生成 initrd，然后重新启动，从而摆脱此错误消息。
答案2
根本问题是阵列创建时末尾有一个 MD 超级块，这意味着开头的超级块仍然可以在其预期偏移量处识别。唯一阻止解析 PV 超级块的原因是 MD 子系统通常先抓取设备。有时，当另一个超级块也可以检测到时，上层会小心地让步，但这可能很脆弱。
有两种方法可以避免这种情况。
- 使用 --metadata=1.2 创建数组，这是自 2010 年以来的默认设置。PV 超级块将移动 512k，并且在未组装的设备上无法识别
- 使用 LVM 的 MD 集成。指定
--type=raidXX到lvcreate或lvconvert。LVM 不会公开未组装的设备。
通常这些预防措施是在创建时采取的，但在您的情况下（raid1 在末尾带有元数据，包含 PV），您可以转换为 LVM 集成 MD 而没有太多麻烦。
确保阵列已同步且文件系统基本正常后，您可以将其拆开，删除两个磁盘上的 raid 超级块（请wipefs仔细阅读手册页，不要误删除 PV 超级块），只删除一个成员上的 PV 超级块，将 VG 扩展到该成员上，然后将逻辑卷转换为--type=raid1 --mirrors=1。最后，在两个磁盘上重新运行 grub-install。