今天升级rhel 5服务器后，我重新启动到新的内核：curr = 2.6.18-371.el5PAE prev = 2.6.18-348.18.1.el5PAE。
在启动顺序中，我看到一条消息指示“逻辑卷pipe理”正在启动，然后几乎立即看到了这个消息，并提供了一个救援shell：
find重复的PV BPF … ayV：使用/ dev / sdc1而不是/ dev / md3。
注意：/ dev / sdc1和/ dev / sdb1是raid1数组/ dev / md3的成员。
因此，我认为lvm2软件认为/ dev / sdc1和/ dev / md3是具有相同UUID的pv，并且lvm2软件select忽略/ dev / md3并使用/ dev / sdc1。
我断电并拔下了驱动器的SDC并重新启动。 意外的是，系统启动没有我没有发现任何问题。 当然，md3已经退化了。
我关掉电源，插上拔下的驱动器，重新启动，系统重新启动，没有发现任何问题。 当然，md3仍然退化，但意外的事情发生了。
故障逻辑卷内的文件系统已挂载。
我执行pvdisplay，看到了上面的错误。 当然，当我试图将sdc1添加回md3时，它不会让我因为lvm2软件正在使用它。
我卸载了文件系统并在lv设备path上运行了e2fsck。 那里没有问题（但应该有问题）。
真的有四个相关的问题（抱歉）。 假设3的答案是“是或不是”，那么4的答案是我所需要的。 我问了前两个，因为我假设我需要理解他们的答案，以理解最后两个答案。
为什么如果逻辑卷最初是由/ dev / md3而不是/ dev / sdc1组成的，那么文件系统是可以的？
不应该/ dev / sdc1不同于/ dev / md3，以防止逻辑卷与内部物理卷相一致吗？ 这可以通过问题1来回答。
我可以通过从/ dev / sdc1中删除光盘信息并将/ dev / sdc1添加到/ dev / md3中来解决我的问题吗？
如果＃3的答案是肯定的，那么我怎样才能解决这个问题，而不会浪费逻辑卷及其文件系统？
一些历史：
我从来没有执行过“pvcreate / dev / sdc1”，所以我不知道为什么会发生这种情况。 不过，/ dev / sdc最近一直困扰着我，因为smartmon（sp？）会告诉我它不能读取智能数据，甚至看不到这个设备。 我将通过（a）重新启动，（b）重新启动+ bios挂起+closures电源+重置sata电缆+电源，或者顺序b，但是replacesata电缆而不是仅仅重新设置来解决问题。
我不确定你是否问过你问的问题，但是/ dev / md3和/ dev / sdb1和/ dev / sdc1是一样的，因为它是一个镜像集。
不，不应该。
不，这会为您造成数据丢失。
N / A
通过修改/etc/lvm.conf文件来更改filter来拒绝sdb *和scd *设备，重新生成initrd，然后重新启动，您可能会摆脱此错误消息。
最根本的问题是数组是在最后用一个MD超级块创build的，这意味着超级块在开始时仍然可以在他们预期的偏移处被识别。 唯一阻止PV超级块被parsing的是MD子系统首先抓取设备; 通常。 有时候，当另一个超级块也是可检测到的时候，上层会小心地产生，但是这可能是脆弱的。
有两种方法可以避免这种情况。
--type=raidXX lvcreate或lvconvert 。 LVM不公开未assembly的设备。 通常这些预防措施是在创build时采取的，但在您的情况下（raid1与最后的元数据，包含一个PV），您可以转换为LVM集成MD没有太多的麻烦。
一旦你确定arrays已经同步，并且文件系统大部分是理智的，你可以反汇编它，在两个磁盘上joinRAID超级块（仔细阅读wipefs ，你不想错误地wipefs PV超级块）只有一个成员的PV超级块，扩展你的VG到那个，并且把你的逻辑卷转换为--type=raid1 --mirrors=1 。 最后，重新运行grub-install到两个磁盘上。