vgreduce error

[William Baines]

I have an odd situation:

I got into a situation (long story) whereby a pvdisplay of a drive shows 500 PE used in the header, yet all PE show as "free" in the detail list. There are no LV allocated to the drive (I'm sure!), yet vgdisplay still shows the drive as belonging to the VG.

I have tried to vgreduce the drive out from the VG, but the command fails, insisting that there are still PE assigned.

How can I force this drive out of the VG?

Can I physically remove the drive from the FC10 and replace with a new drive? I have a spare onhand.

[Mark Mitchell]

you can vgreduce the disk from the volume
with the -f option for Force.

[Sridhar Bhaskarla]

Hi,

Are you very sure that pvdisplay -v /dev/dsk/cxtxdx doesn't show any lv's associated with it?..

Check

pvdisplay -v /dev/dsk/your_dev_file |grep current

If it shows something there, means it's being used.

You can replace this disk and do a vgcfgrestore but it's better to fix the problem first than forcing the drive out.

-Sri

[William Baines]

Thanks for your suggestions!

I am sure that there are no LV on the affected drive. I ran pvdisplay -v /dev/dsk/c6d1t0 and all PE show as "free".

When I run vgdisplay -v I still see the drive:

PV Name /dev/dsk/c6t1d0
PV Status available
Total PE 4340
Free PE 3840
Autoswitch On
===============================================
When I run pvdisplay I get the following:
--- Physical volumes ---
PV Name /dev/dsk/c6t1d0
VG Name /dev/vgora02
PV Status available
Allocatable yes
VGDA 2
Cur LV 0
PE Size (Mbytes) 4
Total PE 4340
Free PE 3840
Allocated PE 500
Stale PE 0
IO Timeout (Seconds) default
Autoswitch On


--- Physical extents ---
PE Status LV LE
0000 free 0000
0001 free 0000
0002 free 0000
0003 free 0000
.
.
.
4337 free 0000
4338 free 0000
4339 free 0000

==========================================
I tried using the vgreduce -f option, but it had no effect. My only other plan at the moment is to physically remove the affected drive and then try the vgreduce -f option again.
The drive is good, only the VG/LV/PV info is out of sync.

[linuxfan]

Hi William,

Do the following
echo 2000?8c+8x|adb /dev/dsk/c6t1d0
and if it returns any info such as LVMRECxxxx then that disk belongs to a VG.

Also what if you try to create a LV on that disk?

Also which LVM patches are installed on your machine?
I know there was a patch in the past PHCO_20870 which fixed a similar problem. The latest LVM cumulative patch is PHCO_24437, Make sure you get the dependcy patches as well in case you decide to install this.

-HTH
Ramesh

[William Baines]

When I run the adb command line I get:
2000: LVMREC016057 3A75 3B82 9C23 6057 3A75 3B82
9F16

I'll check the patch levels as suggested. I know the server has the DEC2000 General Release Bundle loaded.

[William Baines]

I checked the patch level for LVM:
I have PHCO_21630 LVM commands cumulative patch loaded.

A little history on what happened:
I was "borrowing" a mirror disk from one LV to another so that I could then break a mirror set and replace a 10K rpm drive with a faster 15k rpm drive. After the switch I would then return the mirror drive back to the original LV.

I used lvreduce -m 0 ... to reduce the mirror set and then used lvextend -m 1 /dev/vgxxx/lvxxx /dev/dsk/c5t1d0 /dev/dsk/c6t1d0 to add the mirror (I have two paths to the FC10).

I found out that there was also a smaller 2000MB (500 PE) residing on the disk that I missed. Instead of the system failing with a "too many extents" error, it proceeded to add the new mirror to the drive and over-allocated the PE somehow.

I was able to lvreduce -m 0 the newly created mirror and the smaller 2000MB mirror but the 500 over-allocated PE remain.

*sigh*

[Sridhar Bhaskarla · Accepted solution]

vgreduce -f will delete the PV that doesn't belong to the volume group but still sits in /etc/lvmtab.

As Ramesh suggested, try creating few logical volumes on the drive and then delete them. And then try reducing it.

If this doesn't work, I think you are left with no option except to replace the disk.

After replacing the disk, do a vgcfgrestore, then vgchange -a, reduce it from the volume group and re-add it to make it clean.

-Sri

[William Baines]

Hello all,

This weekend I was able to take the system down for maintenance. I unmounted the filesystems on the affected volume group and de-activated it (vgchange -a n ). Then I was able to restore the proper config to the disk (vgcfgrestore -n vgxxx /dev/rdsk/cx/tx/d0).

Thanks to all for the advice and points have been assigned.