recreatevg实验1

实验中某些命令的截图无法直接复制，就放在screen.tar附件中了。另外一个附件是实验中的C程序，目前只支持svg，哪位有兴趣的话可以尝试改写支持ovg和bvg。只要对PV头部以及VGDA的layout有清楚的认识，那写程序就是小菜一碟了。

一、recreatevg的基础
根据man中的解释，recreatevg的作用是Recreates a volume group that already exists on a specified set of disks.Imports and varies on the volume group。也就是根据参数中的PV列表重建VG，然后执行importvg。只要参数中的PV列表完整，就可以重建VG，即使VG中的某些或者全部PV都被pv=clear过。
recreatevg能够重建VG的理论基础基于以下几点：
ü
在PV头部记录了PVID和pv_index
ü
在每个PV的VGDA中都有一个列表，其中记录了PV所属的VG的所有PVID和pvindex
ü
pv=clear以及pv=yes仅修改PV头部的PVID。PV头部的pv_index以及VGDA中的PV列表不受影响。
ü
将PV加入VG会修改PV头部的pv_index以及VGDA中的PV列表。
理论上我们可以手工将参数列表中的PV头部的pv_index都提取出来，然后将VGDA中的pv_index提取出来，进行比对，并设置每个PV头部的PVID以及每个VGDA的PV列表中的PVID。当然这有些前提条件（其实也是recreatevg命令的前提）：
ü
参数中的PV列表完整，这是很显然的要求
ü
每个PV的VGDA是完好的，这样就能以任意一个PV的VGDA的PV列表为准
二、实验
附件中的程序替我们完成提取以及修改PVID的手工操作，但基本思想就是上面所说的那些。假设编译后的可执行程序为my_createvg，则用法就是：
my_createvg -p pvid_prefix hdiskx1 hdiskx2 ......
ü
-p参数指定PVID的前缀。PVID共有16字节，其中最后8个字节都为0。通常前四个字节和主机的序列号有关，中间4个字节则是根据算法得到的某个随机数，总之就是保证这8个字节是惟一的。我简化了下，前4个字节由参数指定，中间4个字节以当前的时间戳为基准，每个PV都递增1。
ü
hdisk列表中不仅包括完整的PV列表，而且至少有3个PV，并且是SVG。也就是说程序仅支持至少包含3个PV的SVG。仅支持SVG是因为我对SVG的头部相对更熟悉，而3个PV的要求是此时每个PV只有1个VGDA，处理起来比较容易。
看一下实验过程：
1，
确认当前状况
#lspv

#lsvg -l testvg

#lslv testfs

#df -m

概括而言，VG中有4个PV和2个LV。其中一个是做了条带化的jfs2，另一个是jfs2log。
2，
pv=clear和pv=yes
#umount /tmp/testfs
#varyoffvg testvg
#exportvg testvg
#pv=clear
#pv=yes
#lspv

3，
my_createvg
#my_createvg

#lspv

#importvg
#lspv

#lsvg -l testvg

#lslv testfs

#mount /tmp/testfs
#df -k

#dd if=/dev/zero of/tmp/testfs/zero.bin bs=1m count=250

4，

三、实验总结
我们对VG中的所有pv都执行了pv=clear和pv=yes，然后通过程序重置了PV头部的PVID、ODM中的PVID以及VGDA中的PV列表，并最终成功的将重建后的VG导入，以及mount了原来的文件系统。对几乎覆盖了所有文件系统块的写操作也成功，说明文件系统是一致的。这个实验也验证了先前的猜想，即基于pv_index可以重建VG，当然也不排除recreatevg采用了其他方法。
四、后记
我认为recreatevg最重要的步骤是重建VG。另外recreatevg还涉及到其他LVM结构，例如-f参数可能涉及到VGSA，-l/-L参数涉及到LVEA和LVCB等。这些结构体我还不太熟悉，留待今后的实验。
当初做这个实验的目的除了验证recreatevg外，还有个想法：在线重建VG。因为recreatevg需要varyoffvg。这可能无法实现：因为VGDA除了在PV中之外，在内存中还有一份。我无法更新内存中的VGDA。也许varyonvg可以做到，这要先了解varyonvg。