HPUX LVM的结构信息（转）
LVM的结构信息/qzone/newblog/v5/editor/css/loading.gif 作者：陈求文
E-mai：crystal.chen.cc@gmail.com]crystal.chen.cc@gmail.com
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 000/11/08 20:49:59
AUTO -12289 896 1 000/11/08 20:49:59
HPUX -12928 904 848 000/11/08 20:50:00
PAD-12290 1752 1580 000/11/08 20:50:00
LABEL BIN 3336 8 099/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 Aug9 12:35:45
<2>获取VG-ID
#echo "0d8208?UY" | adb /dev/dsk/c1t2d0
2010: 2000252410 2000 Aug9 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 设置为一个较大值的结果是怎样的?
原来这个参数是用来设置PE大小的，乘上MaxPEperPV就是一个PV最大的值，默认的4M，乘上最大的PE数65535(65535*4=262140M也就是256G)，因创建时没有改，而硬盘大小是一个500G的硬盘.
在LVM里，一个PV（Physical Volume，物理卷）对应且只对应一个物理硬盘，一个或者多个PV组成一个VG（Volume Group，卷组），而从一个VG里又可以虚拟划分出若干个LV（Logical Volume，逻辑卷），真正的文件系统是创建在LV上面的，可以在LV上建文件系统，也可以不建文件系统而直接使用，这时叫裸设备（raw device）。因为是直接对设备进行数据读写，所以Raw device的性能要比文件系统好，许多数据库系统就是直接存储在裸设备上，但是可管理性比较差，题外话。
LVM系统怎么知道往某一个LV里面存数据时，到底是存放到哪个（些）实际硬盘呢？在LVM系统里，一个PV由若干个PE（Physical Extent）组成，一个LV由若干个LE（Logical Extent）组成，而这些PE和LE之间又有直接的对应关系，这种对应关系被存储在一个叫做“PE/LE对应表”(Translation Table)的表中。Translation Table存放在LVM磁盘上，当VG被激活时才装载到内存中。PE是在创建卷组时创建的，大小由vgcreate的-s参数指定，默认是4M；在同一个VG里面的所有PV的PE大小是一样的，不管实际硬盘的大小和型号是否相同。当LV创建时，LVM系统创建LE并自动维护PE/LE对应表，使得每一个LV里面的LE都可以找到与之对应的PE，从而知道数据该往哪个硬盘写。一般情况下创建LV的时候，系统都是按物理硬盘加入VG的顺序来分配其可用的PV。比如说c0t5d0是第一个加入VG的硬盘，那么默认情况下c0t5d0里的可用PV将最先被用来分配，除非在使用lvextend命令时特殊指定。
在使用vgcreate的-s参数时，PE的大小必须是2的整数倍，一般使用默认值4，这表示卷组上创建的所有逻辑卷都以4MB的增量单位来进行扩充或缩减。由于内核原因，PE大小决定了逻辑卷的最大大小， 4MB的PE决定了单个逻辑卷最大容量为256GB，若希望使用大于256GB的逻辑卷则创建卷组时指定更大的PE。PE大小范围为8KB到512MB。为什么是4而不是8、16...？还有几个LVM的限定，要说明
·一个LV只能属于一个VG（不要去想lvol9先从vg00弄点空间，再从vg01弄点空间）
·一个PV要么独立要么属于且仅属于一个VG（独立时作为Raw Device，性能比较猛）
·vgcrete -l参数将限定一个VG里面能创建的最大LV数量，极限是255
·vgcreate -p参数限定一个VG里面能容纳的最多PV数，极限是255
·内核参数maxvgs限定系统最大的VG数，默认是10，最大可以变态到256
附相关命令：
max_pe设置为它的最大值 65535。
max_pv设置为它的最大值 255。
页:
[1]