problems after I lvmerge back in the opposite direction.......??

[Declan Mc Kay]

Hi,
we have 2 Node Cluster HP-UX 10.20 (2 X D350), we have an application which resides on a shared Volume Group VG02 stored on a HASS Pack. I performed a lvsplit from Node1 on the 3 application logical volumes and this produced 3 split-off logical volumes lov1b, lvol2b, lvol3b. My application upgrade was unsuccessful so I had to revert back so I ran the lvmerge Cmd in the reverse order as follows: lvmerge /dev/vg02/lvol1 /dev/vg02/lvol1b, lvol2b, lvol3b. Now, in order to mount the file system I nolonger have /dev/lvol1...it's /dev/lvol1b, 2b, 3b....this is because I ran lvsplit in reverse order...and thats Fine. All 3 logical volumes mount fine on Node1, however Node2 can't mount them becasue it isn't aware of the 'lvol1b/lvol2b/lvol3b' device files. HP advise me that an easy way around is to just move the /dev/vg02/lvol1b/2b/3b & rlov1b back to lvol1/2/3 & rvol1. I do this on Node1 and can mount the files systems via /dev/vg02/lvol1/2/3 no problem, however Node2 still can't mount these file systems....??? Appreciate if anyone has a solution to this,, and if an explanation as to why Node2 is now nolonger unable to mount them....Thanks!! Declan.

[Bill McNAMARA_1]

be extremely carefull with the syntax of lvmerge...

lvmerge lvol1b lvol1

lvmerge split original

Bill

[linuxfan]

Hi Declan,

From the man page of lvmerge
/Begin/
Whenever a mirrored logical volume is split into two logical volumes, a bit map is stored that keeps track of all writes to either logical volume in the split pair. When the two logical volumes are subsequently merged using lvmerge, the bit map is used to decide which areas of the logical volumes need to be synchronized. This bit map continues to exist until the merge is completed, or one of the logical volumes is extended or reduced, or the system is rebooted.

If there is no bit map available, the entire logical volume is resynchronized.

/End/

when you split a logical volume, it create an identical copy but create a new device file with a different minor number.
When you merge the lvols incorrectly, and then renamed the lvol(from lvol1b to lvol1) you still have the minor number of(the split copy, lvolb). I assume you did all this on one node, without touching the other node, so the device file(with a different minor number) for the lvols on the other node is different.

One of the ways to correct this situation is to export the map files from node1 and reimport the VGs on the other node.

-HTH
Ramesh

[Alan Riggs]

Export to mapfile on system 1
Export on System 2
Import from mapfile on System 2
should work.

You might also be able to simply use mknod to create new device files on system 2 with the appropriate minor numbers.

[Varghese Mathew]

Hi,

I believe the best wor around will be :

1)Export the volume group in preview with shared mode and with map file from the first node
2)Export the current vg with map file in the second node
3)Import the vg in the second node with the map file copied from first node in shared mode.

It should be OK..

Hope this helps
Cheers !!!
Mathew

[Andrew R.]

On the Primary node

#vgexport -p -s -m /tmp/vg02.map /dev/vg02
#rcp /tmp/vg02.map adoptive_node:/tmp

On the Adoptive node
#vgexport vg02
mkdir /dev/vg02;mknod /dev/vg02/group c 64 0x0.... (same like the Prim node)
vgimport -s -m /tmp/vg02.map /dev/vg02

This should work for you, Good luck