AIX LVM基础结构学习心得及FS被误删除后的恢复

ALLSTARS_ORACLE

FS被误删除后的恢复
用rmfs误删除FS，实际上只是删除了LVCB中的信息，超级块中的信息不变，FS中的数据也不会变

这样只要没有向这些空间写入新的数据，都可以做修复的
方法是：按照原来的参数mklv，恢复LVCB中的信息，编辑/etc/filesystem后，就可以mount FS，数据不会丢失

AIX LVM基础结构学习
一、前言
在学习AIX LVM基础结构的过程中，有一些心得，在此和大家一起交流
学习的方式是基于od命令，直接查看相关设备文件的二进制代码，从而分析LVM基础结构，以及LVM高级命令的效果

二、LVM配置信息保存位置
LVM中的配置信息，比如VG、LV、FS保存在两个部分
1）磁盘本身上的数据块中
这部分可以通过低级LVM命令或者od命令直接查看
2）ODM数据库中
ODM数据库中的信息直接源于磁盘数据块，可以通过高级LVM命令或者ODM命令查看

LVM命令会修改 1）和2）中的相关配置信息

ODM和磁盘数据块中信息不一致时，可以通过相应的同步命令，根据磁盘数据块中的信息来更新ODM
三、PV
每个PV头部有一个保留区，主要保留PVID信息

PV保留区如下：
0000200  00c9 bbed 1c16 5948 0000 0000 0000 0000
0000220  0000 0000 0000 0000 0000 0000 0000 0000
*
0000300
注意：其中的 00c9 bbed 1c16 5948就是PVID

当把磁盘设置为pv=yes时，会在保留区生成这样的PVID
反之pv＝clear时，则清除保留区中的PVID

磁盘只有设置为pv=yes，有了PVID后，才能够继续下面后继LVM操作

四、VG
VG是由一个或者多个PV组成
VG的信息保存在VGSA和VGDA中，当磁盘设置为pv=yes时，除了在PV保留区中写入PVID外。另
外保留部分空间给VGSA和VGDA

需要注意的是，创建VG时的参数，如是否支持大VG，会影响分配给VGSA和VGDA的空间大小

当创建VG的时候，向VGSA和VGDA空间里写入相应的参数

根据VG中的PV数量，VGDA在PV上有一份或者两份，具体如下：

PV数                       1#PV   2#PV  3#PV
   1        VGDA数         2
   
   2        VGDA数         2          1
   3        VGDA数         1           1       1

VGSA内容举例如下：
十六进制格式
0010000  4667 a0e6 2462 3f5d 0000 0000 0000 0000
0010010  0000 0000 0000 0000 0000 0000 0000 0000
*
0010fe0  0000 0000 0000 0000 0000 0000 0001 0000
0010ff0  0000 0000 0000 0000 4667 a0e6 2462 3f5d

VGDA内容举例如下：
十六进制格式
0011000  4667 a33b 2aba 553c 00c2 2f2f 0000 4c00
0011010  0000 0113 04cc 9a47 0009 0100 001c 0002
0011020  0003 0832 0000 0001 0001 0000 0000 0000
0011030  0000 0832 0000 0000 0000 0000 0000 0000
0011040  0000 0000 0000 0000 0000 0000 0000 0000
*

ASCII字符格式

0113200    h   d   5  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0
0113210   \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0
*
0113240    h   d   6  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0
0113250   \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0
*
0113280    h   d   8  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0
0113290   \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0
*
01132c0    h   d   4  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0
01132d0   \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0
*
0113300    h   d   2  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0
0113310   \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0

对比 lsvg的输出结果，可以看出来，VG所有信息都包括在了VGSA和VGDA中
比如：
0011000  4667 a33b 2aba 553c 00c2 2f2f 0000 4c00
0011010  0000 0113 04cc 9a47 0009 0100 001c 0002
中的00c2 2f2f 0000 4c00 0000 0113 04cc 9a47即为VGID
VG中的LV名也包括在内
所以ODM中的内容是源自于VGSA和VGDA

对于exportvg来说，只是从ODM中删除了VG相关信息，但是用od查看hdiskX时，上述VGDA信息仍
然存在，因此importvg时，就根据VGDA信息把VG信息重新写入到ODM中

五、LV
VG下划分LV，用于FS或者做raw设备
LV基本分配单位是逻辑块
在每个LV的头部0号逻辑块作为LVCB，用于保存LV配置信息

LVCB内容举例：
ASCII代码
0000000    A   I   X       L   V   C   B  \0  \0   j   f   s  \0  \0  \0
0000010   \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0
0000020   \0  \0  \0  \0  \0  \0  \0  \0  \0  \0   0   0   c   2   2   f
0000030    2   f   0   0   0   0   4   c   0   0   0   0   0   0   0   1
0000040    1   3  \0   h   d   1  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0
0000050   \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0
*
0000080   \0  \0  \0   T   h   u       J   u   n           7       0   6
0000090    :   0   8   :   4   4       2   0   0   7  \n  \0  \0  \0  \0
00000a0   \0   T   h   u       J   u   n           7       0   6   :   0
00000b0    8   :   4   4       2   0   0   7  \n  \0  \0  \0  \0  \0   2
00000c0    2   F   2   F   4   C   0   0  \0   y   m   c  \0   y  \0
00000d0   \0 001  \0 001   /   h   o   m   e  \0  \0  \0  \0  \0  \0  \0
00000e0   \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0

从中可以看出，LVCB中有mount点等相关信息

LVCB被破坏后，可以用低级命令putlvcb来修复，或者直接通过编辑二进制文件来修复

六、FS
FS的配置信息保存在超级块中，每个FS有两个超级块
主超级块在1号逻辑块，次超级块在31号逻辑块

超级块内容举例：

ASCII格式
0001000    e 207   !   C  \0  \0  \0  \0  \0  \0   @  \0  \0  \0  \0 003
0001010   \0  \b  \0  \0 020  \0  \0  \0   /   h   o   m   e  \0   /   h
0001020    o   m   e  \0  \0  \n  \0 003 001  \0  \0  \0   F   g   ?  ?
0001030   \0  \0  \0 001  \0  \0 002  \0  \0  \0  \b  \0  \0  \0  \0  \0
0001040   \0  \0  \0  \0  \0  \f      \0  \0  \0  \0  \0   F   g   ?025
0001050   \0  \0  \0  \0   F   g   ?  ? \0  \0  \0  \0  \0  \0  \0  \0
0001060   \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0
*
0001c10   \0  \0  \0  \0  \0  \0  \0  \0
0001c18

十六进制格式
0001000  6587 2143 0000 0000 0000 4000 0000 0003
0001010  0008 0000 1000 0000 2f68 6f6d 6500 2f68
0001020  6f6d 6500 000a 0003 0100 0000 4667 a0f2
0001030  0000 0001 0000 0200 0000 0800 0000 0000
0001040  0000 0000 000c 2000 0000 0000 4667 a215
0001050  0000 0000 4667 a1ae 0000 0000 0000 0000
0001060  0000 0000 0000 0000 0000 0000 0000 0000
*
0002000

对比lsfs结果，同样可以大体看出超级块各个byte的定义
注意：6587 2143是幻数，如果crfs是采用了默认参数，则幻数为 4321 8765

如果主超级块被破坏，可以通过dd拷贝次超级块来修复，或者直接编辑二进制文件来修复

FS被误删除后的恢复
用rmfs误删除FS，实际上只是删除了LVCB中的信息，超级块中的信息不变，FS中的数据也不会变

这样只要没有向这些空间写入新的数据，都可以做修复的
方法是：按照原来的参数mklv，恢复LVCB中的信息，编辑/etc/filesystem后，就可以mount FS，数据不会丢失

七、总结
上面是我学习LVM的一点体会，主要用的命令如下：

# od -x/c -N 64 /dev/hdisk1 +0200|more   PV保留区

# od -x/c /dev/hdisk1 +0x10000|more  VGSA
# od -x/c /dev/hdisk1 +0x11000|more  1# VGDA

# od -x/c /dev/hdisk1 +0x118400|more  2 # VGDA

# od –c/x  /dev/myfs00 +0x1000  主超级块
# od –cx  /dev/myfs00 +0x1f000  次超级块

建议大家在做LVM操作的时候，可以多用od查看设备文件二进制代码，这样可以更好地了解LVM命
令执行的效果，对于LVM基础结构有更多的了解


上面是我学习LVM的一点体会，主要用的命令如下：

# od -x/c -N 64 /dev/hdisk1 +0200|more   PV保留区

# od -x/c /dev/hdisk1 +0x10000|more  VGSA
# od -x/c /dev/hdisk1 +0x11000|more  1# VGDA

# od -x/c /dev/hdisk1 +0x118400|more  2 # VGDA

# od –c/x  /dev/myfs00 +0x1000  主超级块
# od –cx  /dev/myfs00 +0x1f000  次超级块

建议大家在做LVM操作的时候，可以多用od查看设备文件二进制代码，这样可以更好地了解LVM命
令执行的效果，对于LVM基础结构有更多的了解