Is there a way to see VG disks in running kernel

[Alan Wyskowski]

Does anyone know of a way to list out the disks the running kernel thinks it has for a particular volume group. I found a volume group on one of our servers that says the running kernel thinks it has 103 and there are only 102 in the volume group. I'm trying to see which disk the kernel thinks it has compared to what the volume group has. I already did all of the steps comparing various and can't find any missing and I don't want to do the vgreduce -f until our maintenance window. Thanks for any assistance. I was trying adb, but can't seem to find the right key word to get the listing I need.

[Joseph C. Denman]

Not sure, put I think this is what you are looking for:

vgdisplay -v

Will show you all vg with associated lv and pv

Hope this helps...

...jcd...

[Alan Wyskowski]

Actually, the vgdisplay -v shows all of the disks in the volume group, but the kernel structures in /dev/kmem somewhere think it has 103 and that was the list of disks I was trying to list. Thanks for the reply.

[A. Clay Stephenson]

First do a strings /etc/lvmtab. This will list the disks that should be there. Next do a vgdisplay -v vgxx. Note the PV Status output - for good drives it should indicate 'available'.

Clay

[Patrick Wallek]

Do a 'strings /etc/lvmtab' I think this will show you what you want.

If the lvmtab is incorrect you can move it 'mv /etc/lvmtab /etc/lvmtab.bad' and then run the vgscan command. Do a 'man vgscan' for more info.

[linuxfan]

Hi Alan,

You could do a
"vgscan -p -v > /tmp/vgscan.out"

Look for disks that are not configured. Also

strings /etc/lvmtab > /tmp/lvmtab.txt
will list out all the disks belonging to all the VGs on the system

-Ramesh

[James R. Ferguson]

Hi Alan:

/etc/lvmtab (as you are probably aware) can be listed with the 'strings' command. Knowledge Base document #KBRC00000632 offers a detailed procedure for attempting to resolve the descrepency.

...JRF...

[Sridhar Bhaskarla]

I am hoping that someone will come up with an option with adb to find out what's in there in kernel.

Meanwhile, when you do an lvlnboot -v, it is going to show the disk that is not part of the volume group. Your vgdisplay -v also should give out the error.

How about trying like this?.

vgdisplay -v 2> /tmp/vgdisplay.err
lvlnboot -v 2 > /tmp/lvlnboot.err

verify these two error files and you may get the disk.

Also, try doing a vgchange -a y on this volume group and see what error you get.

-Sri

[Jeff Gyurko]

What the system thinks is configured in the volume groups can indeed be listed with "strings /etc/lvmtab"

If you find a discrepancy check the volume group where the discrepancy is with vgdisplay.

vgdisplay /dev/vg??

Note on the output the CURR PV and ACT PV lines. These numbers should be identical. If not, then you have a discrepancy somewhere. I would not force the reduce just to satisfy the system until I'm sure why there is such a discrepancy. If the vgdisplay has a discrepancy you should see errors on the vgdisplay output about "Can't query Physical..." You've then got a bad disk somewhere.

If the numbers for CURR and ACT jive, then the problem is with the lvmtab, then I would try to move lvmtab to lvmtab.old, then do a vgscan.
Just make sure you know why there is a discrepancy.

[Madhu Sudhan_1]

Alan !

If you want to look at or query kernel datastructures for the disks, use ioscan -k. This queries Kernel and doesn't scan for the hardware.

...Madhu