Discripency on LV's and PV's

[Ganesan R]

Hi All,

Could someon tell me the steps to rectify the discrepancies on vgdisplay output?

# vgdisplay -v /dev/racdbp_clon |more
--- Volume groups ---
VG Name /dev/racdbp_clon
VG Write Access read/write
VG Status available
Max LV 255
Cur LV 17
Open LV 16
Max PV 255
Cur PV 18
Act PV 17
Max PE per PV 7500
VGDA 34
PE Size (Mbytes) 16
Total PE 34901
Alloc PE 34901
Free PE 0
Total PVG 0
Total Spare PVs 0
Total Spare PVs in use 0

There is discrepancy in Cur LV:Open LV and Cur PV:Act PV

I think someone did improper lvm config in the past. Now I could not find the missing lv to reduce/remove that lv using pvkey.Because of that vgreduce -f also failing with this message.
# vgreduce -f /dev/racdbp_clon
Not all extents are free. i.e. Out of 1026 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

[Steven E. Protter · Accepted solution]

Shalom,

Cur PV 18
Act PV 17

Normally this is caused by the removal of a physical volume from the volume group.

If there are extents on the missing physical volume it would explain all of the impact.

SEP

[Ganesan R]

Hi SEP,

That's why I tried vgreduce -f to remove the missed pv's. But it is not allowing since some lv's are created on the missed pv.

I am not able to find which lv resides on the missed pv since Cur LV:Act LV is shows some discrepancy. So first I should fix LV discrepancy before I fix PV discrepancy.

How do i fix LV discrepancy?

[Patrick Wallek]

Post, or better yet attach, the full output from your 'vgdisplay -v' command. Perhaps seeing all of the output will help.

[Steven E. Protter]

Shalom again,

Some trial and error is possible.

I just had the same problem with my pair of HP-UX systems with JBOD.

cd /etc

mv lvmtab lvmtab.save
vgscan -a -v

Then you may need to activate/deactivate the volume group (I forget).

vgreduce -f

Basically I went through a laundry list of what I remembered and what I could find in the forums until I resolved the problem, which was vg00 had a disk on the JBOD, thought extents were allocated. I'd moved and pulled the disks out of the jbod and hadn't bothered to get them back in the same spot.

I may have tried exporting the volume group and then importing it.

Wish I'd taken better notes.

SEP

[Ganesan R]

Hi Patrick,

attached "vgdisplay -v vgname" output.

[Sharma Sanjeev]

Hi Ganesan

Could you pleae check lvol16... /dev/racdbp_clon/lvol16 & paste lvdisplay -v output for this LV ( only Disks used for this LV )

Regards
Sanjeev

[Ganesan R]

Hi Sanjeev,

Nothing wrong in the logical volume you specified. It just spread across two disks.

# lvdisplay -v /dev/racdbp_clon/lvol16 |more
--- Logical volumes ---
LV Name /dev/racdbp_clon/lvol16
VG Name /dev/racdbp_clon
LV Permission read/write
LV Status available/syncd
Mirror copies 0
Consistency Recovery MWC
Schedule parallel
LV Size (Mbytes) 65696
Current LE 4106
Allocated PE 4106
Stripes 0
Stripe Size (Kbytes) 0
Bad block NONE
Allocation strict
IO Timeout (Seconds) default

--- Distribution of logical volume ---
PV Name LE on PV PE on PV
/dev/dsk/c7t8d2 2053 2053
/dev/dsk/c11t2d7 2053 2053

[Steven E. Protter]

Shalom again,

strings /etc/lvmtab

Compare that to the output from the attached report to identify the missing PV

SEP

[Ganesan R]

Hi SEP,

lvmtab contains only 17 disks.

Any other solution from anyone?