In vgdisplay Cur LV != Open LV

[Steve Bonds]

On one of our systems I see that the current number of logical volumes in vg00 does not equal the number of logical volumes currently open. The host does not seem to have any unusual problems because of this.

There are 16 pairs of files in the /dev/vg00 directory, which matches the 16 "open" LVs. However, there are 18 reported as "Cur LV".

Unfortunately, due to additions/deletions the minor numbers are all over the map ranging from 0x000001 to 0x00001c.

How can I find out which ones are missing? Are there other things which could cause the Cur LV to not match Open LV?

[Patrick Wallek]

Can you post what you are looking at so we can see it as well? It would be a great help.

[S.K. Chan · Accepted solution]

My guess is the device file for the 2 "mysterious" LVs are were deleted, that's why Cur LV does not match Open LV. The minor numbers are increment (eg: 0x000001 , 0x000002, 0x000003 and so on). So it goes from 0->9,a->f and 10->11 (ie 18 all together for your case). Now all you have to do is look in /dev/vg00 and find out which minor number is missing.
So for instance 6 and 7 are missing. Before that for all the disks (PVs) in vg00, run this..
# pvdisplay -v /dev/rdsk/cXtYdZ | more
==> I think in the extents where the missing LV is you should see "???" in the output.
If you se it proceed ... we have to recreate the device file until the correct minor number is found for the pvdisplay to NOT show "???".
Now you manually create the "missing LV" (call it lvol99)
# mknod /dev/vg00/lvol99 b 64 0x000006
# mknod /dev/vg00/rlvol99 c 64 0x000006
Run the "pvdisplay" again and if you still see "???", remove the "lvol99" file and recreate it with the next minor number. Repeat till you get the correct one.
As you can see it can get quite messy. ANy additional input from you will help.

[Steve Bonds]

S.K.:

I had hoped to avoid the brute-force approach-- but it worked! Thanks for suggesting it.

I used "ls -l /dev/vg00 | sort +5" to give me a nice list of all the LVs, sorted in minor number order.

Then I used a manual list of missing minor numbers to build a script to create all the devices:

foreach minor in 09 0c 10 11 12 14 15 16 17 18 19 1b; do echo mknod /dev/vg00/mia_${minor} c 64 0x0000${minor}; echo mknod /dev/vg00/rmia_${minor} b 64 0x0000${minor}; done > /tmp/make-minors.sh

Then I just ran "sh /tmp/make-minors.sh" (after verifying that it looked good)

Now "pvdisplay -v" shows me which LVs were missing but still allocated. Now for a little judicious use of "lvremove"...

Thanks for the help.

PS: Here's what I saw that was odd: [Note the Cur LV vs. Open LV]

# vgdisplay vg00
--- Volume groups ---
VG Name /dev/vg00
VG Write Access read/write
VG Status available
Max LV 255
Cur LV 18
Open LV 16
Max PV 16
Cur PV 2
Act PV 2
Max PE per PV 2500
VGDA 4
PE Size (Mbytes) 4
Total PE 4338
Alloc PE 3964
Free PE 374
Total PVG 0
Total Spare PVs 0
Total Spare PVs in use 0

PPS: It was "19" and "1b" that had been removed without removing their allocated logical extents.

[S.K. Chan]

Cool ! It's good to see you got more creative than me. I merely point the way, you completed the journey :)

[Steve Bonds]

A note for future searchers who might try this:

I reversed the character and block devices in my mini-script. It should be instead:

foreach minor in 09 0c 10 11 12 14 15 16 17 18 19 1b; do echo mknod /dev/vg00/mia_${minor} b 64 0x0000${minor}; echo mknod /dev/vg00/rmia_${minor} c 64 0x0000${minor}; done > /tmp/make-minors.sh

(The "b" and "c" were reversed.)