LVM error:lvdisplay可以找到逻辑卷的信息,但是/dev/mapper/中却不存在
今天在配置服务器的时候遇到了一个问题,大概的情况如下所示:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 |
[root@oracle ~]# lvdisplay --- Logical volume --- LV Name /dev/oradata/lv_oradata VG Name oradata LV UUID lDmZ35-8sQe-Lfaf-Ghjr-o9U9-Lj7s-SWRNS4 LV Write Access read/write LV Status NOT available LV Size 2.86 TB Current LE 749732 Segments 6 Allocation inherit Read ahead sectors auto --- Logical volume --- LV Name /dev/VolGroup00/LogVol00 VG Name VolGroup00 LV UUID Ji1vb1-1JZr-UaA2-pf4P-Glxp-JvTm-sMyBsF LV Write Access read/write LV Status available # open 1 LV Size 303.81 GB Current LE 9722 Segments 1 Allocation inherit Read ahead sectors auto - currently set to 256 Block device 253:0 --- Logical volume --- LV Name /dev/VolGroup00/LogVol01 VG Name VolGroup00 LV UUID 9ebUzh-AOIs-KM7S-D2fH-8Rcj-iS3j-FPKozg LV Write Access read/write LV Status available # open 1 LV Size 253.94 GB Current LE 8126 Segments 1 Allocation inherit Read ahead sectors auto - currently set to 256 Block device 253:1 [root@oracle ~]# [root@oracle ~]# ls -l /dev/ | grep --color oradata [root@oracle ~]# ls -l /dev/ | grep --color Vol drwxr-xr-x 2 root root 80 Jun 17 07:25 VolGroup00 [root@oracle ~]# [root@oracle ~]# ls /dev/mapper/ control VolGroup00-LogVol00 VolGroup00-LogVol01 [root@oracle ~]# |
如上所示:
逻辑卷“oradata”是存在的,但是在/dev中却无法找到。
发生这个问题的场景是这样的:
Linux操作系统运行在华为的融合刀片服务器(Tecall E9000)上,共享存储为融合刀片服务器提供的,并分配给了上面的操作系统。
将它们做成了LVM:oradata
但是,重启操作系统后,发现共享存储掉线。(原因未知,貌似是E9000的BUG?)
华为的工程师在E9000的控制台上手动挂载共享存储后,操作系统上可以看到共享存储了,但是访问逻辑卷的时候,却出现了上述代码所示的问题。
事实上,逻辑卷的元信息是记录在磁盘头的,如下:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 |
逻辑卷“VolGroup00”的一块磁盘的头信息: [root@oracle ~]# strings /dev/sda2 | head -n 15 LABELONE LVM2 001ZQ16dRiQiTsgGk06IbWiBYjCDRjs20fn LVM2 x[5A%r0N*> VolGroup00 { id = "069hEc-qgM2-s15J-BkvR-7sXQ-HCe1-brW9LW" seqno = 1 status = ["RESIZEABLE", "READ", "WRITE"] flags = [] extent_size = 65536 max_lv = 0 max_pv = 0 metadata_copies = 0 physical_volumes { pv0 { id = "ZQ16dR-iQiT-sgGk-06Ib-WiBY-jCDR-js20fn" [root@oracle ~]# 逻辑卷“oradata”的一块磁盘的头信息: [root@oracle ~]# strings /dev/sdb1 | head -n 15 LABELONE LVM2 001SCk0I6P6WRbDfhgXvDjsc7lMO2Fmpdiu ! LVM2 x[5A%r0N*> oradata { id = "teBQUU-bl1E-f5Nf-fPsM-MJQh-mxWw-b0RSYQ" seqno = 1 status = ["RESIZEABLE", "READ", "WRITE"] flags = [] extent_size = 8192 max_lv = 0 max_pv = 0 metadata_copies = 0 physical_volumes { pv0 { id = "SCk0I6-P6WR-bDfh-gXvD-jsc7-lMO2-Fmpdiu" [root@oracle ~]# |
而指令“pvdisplay”、“vgdisplay”、“lvdisplay”均以磁盘的头信息为依据。
故而,当Linux重新访问到共享设备的时候,lvdisplay可以读到数据。
但由于此时,操作系统已经启动,因为没有重新对磁盘设备重新读取,故而文件系统中诸如“/dev/mapper”…都没有就绪。
因此,解决上述问题,你需要重新应用逻辑卷即可。
具体操作如下:
Command:
1. partprobe
2. lvchange -a y 【逻辑卷名称】
1 2 3 4 5 6 7 8 9 10 11 12 13 |
[root@oracle ~]# partprobe [root@oracle ~]# [root@oracle ~]# ls /dev/mapper/ control VolGroup00-LogVol00 VolGroup00-LogVol01 [root@oracle ~]# lvchange -a y oradata [root@oracle ~]# ls /dev/mapper/ control oradata-lv_oradata VolGroup00-LogVol00 VolGroup00-LogVol01 [root@oracle ~]# [root@oracle ~]# ls /dev/ | grep oradata oradata [root@oracle ~]# ls /dev/oradata/ lv_oradata [root@oracle ~]# |
这样,就可以正常使用了:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
[root@oracle ~]# df -h Filesystem Size Used Avail Use% Mounted on /dev/mapper/VolGroup00-LogVol00 295G 16G 264G 6% / /dev/sda1 99M 13M 81M 14% /boot tmpfs 126G 0 126G 0% /dev/shm [root@oracle ~]# [root@oracle ~]# mount /dev/oradata/lv_oradata /oradata [root@oracle ~]# [root@oracle ~]# df -h Filesystem Size Used Avail Use% Mounted on /dev/mapper/VolGroup00-LogVol00 295G 16G 264G 6% / /dev/sda1 99M 13M 81M 14% /boot tmpfs 126G 0 126G 0% /dev/shm /dev/mapper/oradata-lv_oradata 2.9T 201M 2.7T 1% /oradata [root@oracle ~]# [root@oracle ~]# ls /oradata/ lost+found [root@oracle ~]# |
————————————————————————————————————————
Done。
在修复这个问题的时候,我也做过fdisk /dev/sdb这样的操作去影响逻辑卷“oradata”的底层PV,但后来,并没有对LVM本身构成破坏。
这说明了fdisk命令对于磁盘的操作是打标签,而非MS Windows中的格式化那般,会干掉数据。
尽管如此,在正式操作的时候还是需要小心慎行。