vgreduce -f error

[Ken Scharpell]

Hi,

We moved some filesystems over the weekend by splitting mirrors, exporting the VGs and reimporting the VG's from the mirrors. All worked aok except the usual problem with the new VG showing twice the number of disks than we have. Easy to fix, first do vgreduce -f, then rm the lvmtab file, vgscan etc.

On one of our servers we get an error though doing the vgreduce -f

Not all extents are free. i.e. Out of 4355 PEs, only 0 are free.
You must free all PEs using lvreduce/lvremove before the PV can be removed.
Example: lvreduce -A n -m 0 /dev/vg01/lvol1.
lvremove -A n /dev/vg01/lvol1
Here's the map of used PEs

--- Logical extents ---
LE LV PE Status 1
0000 lvol1 0000 ???
0001 lvol1 0001 ???

Can anybody shed some light on why and whats the resolution?

Thanks.

[Stefan Farrelly]

Ken,

did everything on the vgimport go fine ? no errors ? import aok, right number of lvols (from map file), can mount cleanly, then you moved the lvolXb's to lvolX and rlvols too, then you can sill mount aok ?

[Ken Scharpell]

It went clean as a whistle. Did this on another server and it worked fine - even the vgreduce -f worked aok. But the patch levels on the 2 boxes are different. The one it worked on is March2002 and the one it failed on is Jun01. Could it be a patch issue ?

[Martin Johnson]

You did remember to do a lvreduce -m 0 prior to moving the disks?

[Roberto Arias]

hello:

Are you reduced the swap?

[Thayanidhi]

Hi,

If you get ??? in status field
I think the PV is configured in LVM and currently the PV is unavailable or bad.
You may have to replace that disk, and restore LVM configuration.
It's only my feeling.

[Martin Burnett_2]

Hello Ken,

The vgreduce -f command will always fail if the Logical Volume Manager beleives that physical extents (pe) on the physical volume (pv) you are trying to remove are allocated to a logical volume. The volume group status area (VGSA) contains and tracks pe data that determines whether the extent is stale/current or unknown which is shown as ??? next to the pe in lvdisplay. This data is not altered during a vgexport. By running the command:

# pvdisplay -v /dev/vg01/lvol[1-9] |grep ?

you will find any "unknown" physical extents. These must be resolved before vgreduce will work.

Which disk is being displayed that the LVM thinks these pe are assigned in your lvdisplay?

Refer to doc KBRC00000632

Thanks for participating in the forums,

Martin
Chaos reigns within. Reflect, repent, and reboot. Order shall return.