LVM的结构信息
[img]/qzone/newblog/v5/editor/css/loading.gif[/img] 作者:陈求文
E-mai:[email=[ft=#0000ff,,]crystal.chen.cc@gmail.com]crystal.chen.cc@gmail.com[/email]
MSN:cqwlyh@263.net
该笔记中要用到以下缩写:
1. VG
Volume Group
2. LV
Logical Volume
3. PV
Physical Volume
4. PVG
Physical Volume Group
5. PE
Physical Extent
6. LE
Logical Extent
7. FS
File System
8. VGRA
Volume Group Reserved Area
9. VGDA
Volume Group Descriptor Area
10. VGSA
Volume Group Status Area
11. MCR
Mirror Consistency Record
12. PVRA
Physical Volume Reserved Area
13. BDRA
Boot Data Reserved Area
LVM结构信息
LVM的结构信息存在于每块LVM硬盘开头的保留区域中(PVRA,VGRA),这块区域被叫做LVM表头(LVM header)。下面的图显示了LVM盘的结构:
1. 非启动盘
|------------------|
| PVRA |
|------------------|
| VGRA |
|------------------|
| |
| |
| |
| User Data |
| |
| |
| |
|------------------|
| Bad block pool |
|------------------|
2. 启动盘
|------------------|-----
| LIF header |
|------------------|
| PVRA |
|------------------|
| BDRA | |-->2912K
|------------------| /
| LIF volume | /
|------------------| /
| VGRA | /
|------------------|-----
| |
| |
| |
| User Data |
| |
| |
| |
|------------------|
| Bad block pool |
|------------------|
注意:
a. 启动盘的LVM表头(LVM header)总是2912KB,而对于非启动盘来说,LVM header的大小是不固定的。它取决于VG的配置参数PVs/VG(-p max_pv),PEs/PV(-e max_pe)和LVs/VG(-l max_lv),但是一般来说,非启动盘的LVM header的大小总是比启动盘的要小一些。而且,VG的VGRA一定不能大于一个单独的块的大小。
b. 安腾(Itanium systems)系统(UX11.20,11.22,11.23)在硬盘的开头区域有一个100MB的EFI区域。这部分的详细资料可以参考安腾系统的相关章节。
PVRA,BDRA和VGRA
1. PVRA
对VG中的每个PV来说,PVRA是唯一的,它包括:
<1>LVMREC用PV-ID,VG-ID,VG中PV的数量,PE的大小来描述PV;VGRA,BDRA(如果有),BBDIR,User Data和Bad Block Pool的开始点和空间大小;如果配置了ServiceGuard Cluster的话,还包括Cluster ID和Cluster Lock Area的相关信息。
<2>BBDIR(Bad Block Directory,用来维护Bad Block Pool的信息)
2. BDRA(使用pvcreate -B命令的时候才会产生)包含了启动的相关信息,例如:
<1>启动VG中的PVs信息
<2>Boot/Swap/Root LVs(major/minor numbers,等等)的信息
3. 对同一VG当中的任何PV来说,VGRA都是相同的,它包括:
<1>VGDA用下列信息来描述VG:
a. VG-ID,限定max_lv,max_pv,max_pe
b. 每个LV的信息:LV flags,size,schedule strategy,number of mirrors,stripes,stripe size,等等
c. 每个PV的信息:PV-ID,PV size,PV flags,Extent mapping,等等
<2>VGSA包含了丢失的PVs的信息(missing PVs)和stale extents的信息
<3>MCRs是用来处理Mirror Write Cache handling的
LIF表头(LIF Header)和LIF卷(LIF Volume)
LIF是Logical Interchange Format的缩写。对每块启动盘来说,LIF表头(LIF header)占据了硬盘最开头的8KB的空间。它包含了位于BDRA之后的LIF卷(LIF volume)的目录。可以用lifls(1M)命令来显示:
#lifls -l /dev/rdsk/c1t6d0
volume ISL10 data size 7984 directory size 8
filename type start size implement created
===============================================================
ISL -12800 584 306 0 00/11/08 20:49:59
AUTO -12289 896 1 0 00/11/08 20:49:59
HPUX -12928 904 848 0 00/11/08 20:50:00
PAD -12290 1752 1580 0 00/11/08 20:50:00
LABEL BIN 3336 8 0 99/10/08 02:48:02
LIF卷(LIF volume)包含了启动所需要的文件:ISL,HPUX,LABEL和AUTO(给自动引导用的)。可以查看引导的相关章节来获得LIF文件的详细描述。
PV-ID和VG-ID
任何PV都有唯一的8位(byte)长的标识,这就是PV-ID。VG-ID对属于该VG的PV来说,也是唯一的,而且也是8位长。它们都保存在PVRA当中。可以用lvm命令来显示完整的LVM header:
#lvm -p -d /dev/rdsk/c1t2d0 | more
......
......
/* The physical volume ID. */ 2000252410 965817345
i.e. pvcreate(1m) was run on CPU with ID 2000252410 at Wed Aug 9
12:35:45 2000
/* The volume group ID. */ 2000252410 965817462
i.e. vgcreate(1m) was run on CPU with ID 2000252410 at Wed Aug 9
12:37:42 2000
......
如果lvm命令在某个HP-UX版本中不能使用的话,还可以使用任何HP-UX系统都能够使用的命令来读取PV-ID和VG-ID
1. 使用xd(1)命令来获取PV-ID和VG-ID
#xd -j8200 -N16 -tu /dev/rdsk/c1t2d0
0000000 2000252410 965817345 2000252410 965817462
PV CPU-ID PV timestamp VG CPU-ID VG timestam
从以上信息可以知道如下的信息:
<1>pvcreate和vgcreate运行在systemID(uname -i)为2000252410的系统上
<2>pvcreate执行的时间戳(timestamp)是965817345(seconds after Jan 1st 1970 0:00 UTC)
<3>vgcreate执行的时间戳(timestamp)是965817462(117 seconds later)
2. 使用adb(1)命令来获取PV-ID和VG-ID
<1>获取PV-ID
#echo "0d8200?UY" | adb /dev/dsk/c1t2d0
2008: 2000252410 2000 Aug 9 12:35:45
<2>获取VG-ID
#echo "0d8208?UY" | adb /dev/dsk/c1t2d0
2010: 2000252410 2000 Aug 9 12:37:42
vgcfgbackup(1M)
LVM表头(LVM header)有一份备份存放在文件系统当中(/etc/lvmconf/*.conf)。任何对LVM结构的改动,例如通过LVM命令lvcreate,lvchange,vgextend等等,都会自动调用vgcfgbackup(1M)命令来保存一次。
你也可以在任何时候运行vgcfgbackup(1M)命令来手工保存:
#vgcfgbackup vgXY
Volume Group configuration for /dev/vgXY has been saved in /etc/lvmconf/vgXY.conf
保存的文件内容是二进制(binary)的,不过也可以使用vgcfgbackup的-l选项来显示VG中所包含的硬盘的:
#vgcfgbackup -l -n vgXY
Volume Group Configuration information in "/etc/lvmconf/vgXY.conf"
VG Name /dev/vgXY
---- Physical volumes : 1 ----
/dev/rdsk/c1t6d0 (Bootable)
如果LVM header被误写了,或者崩溃了,就可以通过vgcfgrestore命令来恢复该信息。
通常,当一个硬盘坏了以后,可以通过vgcfgrestore命令来将备份的信息回写到新的硬盘:
#vgcfgrestore -n vgXY /dev/rdsk/c1t6d0
Volume Group configuration has been restored to /dev/rdsk/c1t6d0
注意:
a. 如果你修改了LVM的配置,而又不想备份文件被更新的话,可以使用LVM的相关命令接上"-A n"的参数。不管怎么样,先前的配置可以在/etc/lvmconf/*.conf.old找到
b. vgcfgrestore不会恢复LIF卷(LIF volume),这要通过mkboot命令来恢复
/etc/lvmtab和vgscan(1M)
/etc/lvmtab文件包含了所有使用的VGs和它们所包含的PVs的信息。它主要在使用vgchange(1M)来激活VG的使用使用。lvmtab是一个二进制(binary)的文件,不过可以使用strings(1M)命令来显示其中的内容:
#strings /etc/lvmtab
/dev/vg00
/dev/dsk/c2t0d0
/dev/vgsap
/dev/dsk/c4t0d0
/dev/dsk/c5t0d0
/dev/dsk/c4t1d0
/dev/dsk/c5t1d0
/dev/vg01
/dev/dsk/c6t0d0
注意:这仅仅是lvmtab文件的“可见部分”。它也包含了VG-IDs,所有的VGs,每个VG中的PVs数量和状态信息。额外的被strings命令打印出来的奇怪字符都可以被认为是不重要的而忽略它们。
所有在lvmtab当中的VGs会在系统启动的时候被自动激活。其中的脚本是/sbin/lvmrc,相关的配置文件是/etc/lvmrc。
如果你觉得lvmtab的信息已经不可靠了,那么你可以很简单的使用vgscan(1M)命令来重新生成该文件。不过需要提醒的是,在这么做之前,最好先备份一下该文件:
#cp /etc/lvmtab /etc/lvmtab.20060226
#vgscan -v
所有的警告信息你都可以忽略。
注意:
a. 如果你不删除lvmtab而直接使用vgscan来创建一个新的lvmtab文件,那么是否成功就要取决于文件的内容。当然,你也可以删除lvmtab文件以后使用vgscan命令重新生成一个,不过这个时候需要注意的是,此时没有激活的VG是不会包含在新的文件当中的
b. 在配置了ServiceGuard的系统中,vgscan可能会失败。那么可以安装相关的patch来解决该问题。或者,很简单的,在使用vgscan命令之前先删除/dev/slvmvg文件
c. 当系统正在使用数据复制类的产品,比如BusinessCopy/XP,ContinousAccess/XP,EMC SRDF或者EMC Timefinder的时候,vgscan可能会在VGs中加一些非预想中的PVs
d. vgscan不会注意可选路径(alternate links),它很可能会切换路径(可以参考“PV Links”的相关章)
在 VGDA (volume group discriptor area) 上使用 vgcreate 命令设置较大 max_pe 值的结果是什么XX? 因为较小的或者默认的max_pe 值通常会限制将来向 Volume Group 添加较大的磁盘,因此最好将max_pe 设置为一个较大的数字?VGDA 成数量级的增长。将 max_pe 设置为一个较大值的结果是怎样的?