编辑**我有一个卷组由5个RAID1设备组成一个LVM和格式化的XFS。 第五个RAID设备丢失了RAIDconfiguration（cat / proc / mdstat不显示任何东西）。 两个驱动器仍然存在（sdj和sdk），但他们没有分区。 直到最近，LVM似乎都很高兴地使用sdj。 （做一个pvscan显示了前4个RAID1设备+ / dev / sdj）我从fstab中删除了LVM，重新启动，然后在LV上运行xfs_check。 它跑了大约半个小时，然后停了一个错误。
我再次尝试重新启动，这一次，逻辑卷不再存在。 现在正在寻找/ dev / md5，这已经不存在了（尽pipe它早先使用了/ dev / sdj）。 / dev / sdj有读取错误，但更换SATA电缆后，那些消失，所以驱动器似乎现在罚款。
我可以修改/ etc / lvm / backup / dedvol，将设备更改为/ dev / sdj并执行vgcfgrestore？ 我可以尝试使用pvcreate -uuid KZron2-pPTr-ZYeQ-PKXX-4Woq-6aNc-AG4rRJ / dev / sdj来识别它，但是恐怕会擦除驱动器上的数据
更新：只是改变光电指向/ dev / sdj没有工作
vgcfgrestore - 文件/ etc / lvm / backup / dedvol dedvol 用uuid'KZron2-pPTr-ZYeQ-PKXX-4Woq-6aNc-AG4rRJ'找不到设备。 无法还原1个标记为缺失PV的卷组devvol。 还原失败。
pvscan / dev / sdj：在0：input/输出错误时，4096的0之后读取失败 用uuid'KZron2-pPTr-ZYeQ-PKXX-4Woq-6aNc-AG4rRJ'找不到设备。 用uuid'KZron2-pPTr-ZYeQ-PKXX-4Woq-6aNc-AG4rRJ'找不到设备。 用uuid'KZron2-pPTr-ZYeQ-PKXX-4Woq-6aNc-AG4rRJ'找不到设备。 用uuid'KZron2-pPTr-ZYeQ-PKXX-4Woq-6aNc-AG4rRJ'找不到设备。 PV / dev / sdd2 VG VolGroup00 lvm2 [74.41 GB / 0免费] PV / dev / md2 VG dedvol lvm2 [931.51 GB / 0免费] PV / dev / md3 VG dedvol lvm2 [931.51 GB / 0免费] PV / dev / md0 VG dedvol lvm2 [931.51 GB / 0免费] PV / dev / md4 VG dedvol lvm2 [931.51 GB / 0免费] PV未知设备VG dedvol lvm2 [1.82 TB / 63.05 GB免费] 总数：6 [5.53 TB] /使用中：6 [5.53 TB] / in否VG：0 [0]
vgscan 读取所有物理卷。 可能还要等一下... / dev / sdj：在0：input/输出错误时，4096的0之后读取失败 / dev / sdj：在2000398843904的4096的0之后读取失败：input/输出错误 find使用元数据typeslvm2的卷组“VolGroup00” 使用元数据typeslvm2find卷组“dedvol”
vgdisplay dedvol ---卷组--- VG名称dedvol 系统ID 格式lvm2 元数据领域5 元数据序列号10 VG访问读/写 VG状态可resize MAX LV 0 Cur LV 1 打开LV 0 最大PV 0 Cur PV 5 法PV 5 VG大小5.46 TB PE大小4.00 MB 总PE 1430796 Alloc PE / Size 1414656 / 5.40 TB 免费PE /尺寸16140 / 63.05 GB VG UUID o1U6L1-5WH8-Pv7Z-Rtc4-1qYp-oiWA-cPD246
dedvol {
id =“o1U6L1-5WH8-Pv7Z-Rtc4-1qYp-oiWA-cPD246”
seqno = 10
状态= [“RESIZEABLE”，“READ”，“WRITE”]
flags = []
extent_size = 8192＃4兆字节
max_lv = 0
max_pv = 0
physical_volumes {
pv0 {
id =“Msiee7-Zovu-VSJ3-Y2hR-uBVd-6PaT-Ho9v95”
device =“/ dev / md2”＃仅提示
状态= [“ALLOCATABLE”]
flags = []
dev_size = 1953519872＃931.511千兆字节
pe_start = 384
pe_count = 238466＃931.508千兆字节
}
pv1 {
id =“ZittCN-0x6L-cOsW-v1v4-atVN-fEWF-e3lqUe”
设备=“/ dev / md3”＃仅提示
状态= [“ALLOCATABLE”]
flags = []
dev_size = 1953519872＃931.511千兆字节
pe_start = 384
pe_count = 238466＃931.508千兆字节
}
pv2 {
id =“NRNo0w-kgGr-dUxA-mWnl-bU5v-Wld0-XeKVLD”
device =“/ dev / md0”＃仅提示
状态= [“ALLOCATABLE”]
flags = []
dev_size = 1953519872＃931.511千兆字节
pe_start = 384
pe_count = 238466＃931.508千兆字节
}
pv3 {
id =“2EfLFr-JcRe-MusW-mfAs-WCct-u4iV-W0pmG3”
device =“/ dev / md4”＃仅提示
状态= [“ALLOCATABLE”]
flags = []
dev_size = 1953519872＃931.511千兆字节
pe_start = 384
pe_count = 238466＃931.508千兆字节
}
pv4 {
id =“KZron2-pPTr-ZYeQ-PKXX-4Woq-6aNc-AG4rRJ”
设备=“/ dev / md5”＃仅提示
状态= [“ALLOCATABLE”]
flags = []
dev_size = 3907028992＃1.81935兆兆字节
pe_start = 384
pe_count = 476932＃1.81935兆兆字节
}
}
哇，你的系统坏了。 有了足够的关心和注意力，你可以在/etc/lvm/archives中的LVM状态档案中重build卷组中的LV，但是只要打开备份就可以快得多了（你有备份，对吗？），然后重build系统（这次用一个更强大的RAID设置 – 如果你有10个磁盘，为什么不只是一个大的RAID-10？）。
为了让你放心，我怀疑如果你在LV上运行xfs_check ，它可能会做任何事情来破坏卷组。 更有可能的是已经被洗净了，你还没有注意到。