- 论坛徽章:
- 0
|
LVM案例(关键字VGDA、VGSA、PV头、PVID、VGID)
案例：
主机A、C，A -- 生产机，C -- 测试机
主机A：
#lspv
pv1 0000000000001111 datavg
pv2 0000000000002222 datavg
pv3 0000000000003333 datavg
pv4 0000000000004444 datavg
主机C：
#lspv
pv1 0000000000001111 None
pv2 0000000000002222 None
pv3 0000000000003333 None
pv4 0000000000004444 None
2台主机同时看到4块PV，但仅仅在A上使用
误操作：
在主机C上用PV1强制新建一个testvg
主机C：
#lspv
pv1 0000000000001111 testvg
注意PVID之前就已经识别，未变化过。接着将testvgexport掉，生产环境A的数据库故障。数据库重新启动，成功。应用也正常。
开始擦屁股，A主机上lsvg、lsvg -l、lspv命令都正常，errpt有报错，就是在C机上mkvg的时候，A机报得错，一切看起来似乎很正常，但是内伤严重！！！电话求助larryh，讨论了一番后，尝试过一把synclvodm，无果。
发现对pv做lqueryvg,以及readvgda的时候就不正常了。两块好的的pv里读出的vgda信息，内容完整，且仅有2个地方不同，是PVID和pv_num。而损坏的pv1的VGDA信息已经非常不完整。但是应用正常，起码说明盘里的应用数据是正常的未被损坏。
基本思路：损坏的是PV1的PV头部的信息，得想办法从好盘里恢复。当晚回家，一夜没睡好，睡觉梦到很多命令...
修复：
第二天larryh给出解决方案，将好盘的PV头信息dd出来，修改其中的PVID和pv_num为原PV1的正确数值，
然后把修改好的数据dd回损坏的PV，成功。一切命令正常。
在C主机上做importvg等操作一切正常，故障修复！
修复方法的探寻，关键点有2点
1、PV头里记录了哪些信息？
2、整个PV头的精确的大小是多少？
经过几天断断续续的研究，研究情况如下，欢迎大家讨论！
物理扇区Physical Sector，物理扇区号Physical Sector Number(PSN)
一个扇区=512字节
PV头里的重要扇区的记录信息：
0扇区=512字节
00000080h-00000087h 8个字节记录了PVID
这个可以拿几个系统的PV的头部出来研究，就可以发现。qintl在他的帖子里用
chdev -l hdiskX -a pv=yes
chdev -l hdiskX -a pv=clear的方法来验证过，没有问题。
7扇区=512字节
00000E00h-0000E03h 4个字节 LVMID
00000E04h-0000E13h 16 VGID
00000E14h-0000E17h 4 两份VGDA+VGSA总长度.单位扇区 00 00 10 74 = 4212
00000E18h-0000E1Bh 4 单份VGDA长度.00 00 08 32 = 2098
00000E1Ch-0000E1Fh 4 第一份VGDA起始扇区号. 00 00 00 88 = 136
00000E20h-0000E23h 4 第二份VGDA起始扇区号.00 00 08 C2 = 2242
00000E24h-0000E27h 4 Bad Block Relocation区起始扇区号
00000E28h-0000E2Bh 4 Bad Block Relocation区扇区数
00000E2Ch-0000E2Dh 2 本PV在VG中的编号，从1开始即00 01, 00 02, 00 03 …
00000E2Eh-0000E2Fh 2 PP Size对2的幂
00000E30h-0000E33h 4 单份VGSA长度.单位扇区 00 00 00 08 = 8
00000E34h-0000E37h 4 第一份VGSA起始扇区号.00 00 00 80 = 128
00000E38h-0000E3Bh 4 第二份VGSA起始扇区号.00 00 08 BA = 2234
00000E3Ch-0000E3Dh 2 VGDA和VGSA版本号
00000E3Eh-0000E3Fh 2 VG Type编号
00000E40h-0000E43h 4 LTG大小
00000E44h-0000FFFh 444 保留未用
以上信息在lvmrec.h有完整记录
/* Old LVM record layout
00000E00 LVM___ID VGID__W1 VGID__W2 VGID__W3
00000E10 VGID__W4 AREA_LEN VGDA_LEN VGDAPSN0
00000E20 VGDAPSN1 RELOCPSN RELOCLEN PVnmPPsh
00000E30 VGSA_LEN VGSAPSN0 VGSAPSN1 VERnTYPE
00000E40 LTG_SIZE RESERVED RESERVED RESERVED
00000E50 RESERVED RESERVED RESERVED RESERVED
...
00000FF0 RESERVED RESERVED RESERVED RESERVED
*/
readvgda读出来的信息也跟以上信息相符
对于普通VG需要dd的精确扇区数=128+4212=4340
至于VGDA、VGSA里的信息，参考了qintl的帖子里给出的结构，在此不再累述。VGDA里比较私有的信息是VGID，记录的地方可以看dd出来的东西可以找出来。这次案例让我加深了对LVM的理解，很有益处。在解决问题的过程中，翻看LU上xiaomage、qintl、seventh和鸡哥的类似帖有豁然开朗的感觉。正如larryh原来所说，在LVM上花再多的时间都不为过！
参考资料：
1、larryh的研究成果，整个PV头结构
2、AIX Logical Volume Manager from A to Z_ Introduction and Concepts
3、LU上xiaomage和qintl的两个精华帖
http://bbs.loveunix.net/viewthre ... aomage79&page=1
http://bbs.loveunix.net/viewthre ... aomage79&page=1
4、AIX操作系统下的几个头文件hd_psn.h、lvmrec.h等
讨论：
1、mkvg的操作只是修改了PV头部的保留区域部分信息，而真正的数据区域未动，所以即便mkvg误操作也是可以恢复的。这一点qintl在帖子里说过，案例证明是正确的。
2、我的案例并不复杂，仅仅是误用了mkvg，没有新建lv甚至新建FS的动作，所以只有PV的头部信息需要恢复。如果整个硬盘的数据损坏，只能从现成的好数据里找到MAP信息做恢复，如果连MAP信息都没有，只能构建MAP信息再做恢复。这需要理解更透彻，更细心，不能犯一点错误。
3、案例仅仅针对普通VG。我事后尝试研究BIG VG的PV头结构，没有完成。BIG VG的0扇区和7扇区的内容和普通VG差别不大，很容易读出来。只是VGSA、VGDA的扇区变大了，这在BIG VG的7扇区有记录，两份VGSA的开始扇区号分别变为了128、9216；两份VGDA的扇区号是：384、9472。但BIG VG里的VGSA、VGDA结构，看不出来，找了几个头文件+dd出来的内容识别，不符合，没有继续下去了。不知哪位可以提供?以供研究
欢迎大家讨论！
在此再次特别感谢larryh的强力支持！ |
|
免费注册
发表于 2011-03-23 22:30
