topic Re: vgreduce fails .. physical extents are still in use in Operating System - HP-UX

vgreduce fails .. physical extents are still in use

rleon — Wed, 06 Feb 2008 15:59:02 GMT

Trying to reduce a disk out of a mirrored vg.

vgreduce: Physical volume "/dev/dsk/c6t0d0" could not be removed since some of its
physical extents are still in use.

I have tried to reduce using pk keys and no luck.

# lvreduce -k -m 0 /dev/appsvg00/lvvartibco 1
lvreduce: Couldn't reduce the logical volume:
Device busy
lvreduce: The LVM device driver failed to reduce mirrors on
the logical volume "/dev/appsvg00/lvvartibco".

I found a document with the error but the doc states that the reason for the error is that the lv device files are missing. In this case they are not missing.

the vg does have one stale extent.

Thanks !

Re: vgreduce fails .. physical extents are still in use

Zeev Schultz — Wed, 06 Feb 2008 16:04:43 GMT

vgreduce -f didn't work as well?

Re: vgreduce fails .. physical extents are still in use

Steven E. Protter — Wed, 06 Feb 2008 16:06:39 GMT

Shalom,

Stale extents indicate that something has gone wrong. A disk or mirror has failed.

Ideas to get the vgreduce to work.

1) Remove associated logical volumes (lvremove)
Obviously back up the data first and umount any filesystems.
2) vgreduce -f (follow the instructions afterward. This is a relatively dangerous thing to do, but sometimes you have to do it.

SEP

Re: vgreduce fails .. physical extents are still in use

Eric SAUBIGNAC — Wed, 06 Feb 2008 18:15:55 GMT

Bonsoir,

You said "Trying to reduce a disk out of a mirrored vg."

--> Why do you want to do that ? If the disk is out work, HP is supposed to change it ASAP. There is no need to unmirror the LVs. The procedure is rather simple and can be done online. Here is the general guideline : change the failed disk, ioscan, vgcfgrestore on the new disk, reactivate the vg, then vgsync if necessary.

Anyway, you may still want to unmirror, just because your maintenance contract is expired or anything eles ...

So why "lvreduce -k ... 1" and not "lvreduce -k ... 0" ? I mean have you localized on which disk there is "one stale extent" ? (if the disk is really HS, you may have now more than just one stale extent).

Could you control output of "lvdisplay -k -v dev/appsvg00/lvvartibco | egrep -i stale". Is it really on pvkey 1 and always on the same pvkey ? You should also control all LV on this VG.

Knowing that it will be easier to give valuable advice.

Regards

Eric

Re: vgreduce fails .. physical extents are still in use

rleon — Wed, 06 Feb 2008 19:08:57 GMT

the disk was replaced ..

ran vgcfgrestore to restore ..

After everything synced up I still had one bad stale extent.

I was going to break the mirror and re-mirror.

All of the lv's where fine until I got to the one that had one stale extent. When I tried to break it was when I got the error ..

# lvreduce -m 0 -A n /dev/appsvg00/lvvartibco /dev/dsk/c6t0d0
lvreduce: Couldn't reduce the logical volume:
Device busy
lvreduce: The LVM device driver failed to reduce mirrors on
the logical volume "/dev/appsvg00/lvvartibco".

Re: vgreduce fails .. physical extents are still in use

TTr — Wed, 06 Feb 2008 20:41:13 GMT

You probably have a single bad extend on the first disk and not on the one you replaced. Run pvdisplay and look at the PEs on the "lwartibco" (sorry to see that you are using tibco :) )

Under this assumption (bad PE on the first disk) you can do the following

Run a read test on the first disk using the dd command.

You don't see any file read errors because by luck that extend has no data in it.

You need to create anothr LV and move the tibco volume to this new LV and delete the old LV altogether.

pvmove may be an option here if you have another disk to use temporarily.

Re: vgreduce fails .. physical extents are still in use

Vivek_Pendse — Wed, 06 Feb 2008 22:01:21 GMT

Hi,
Check the lvdisplay output, it will show you the conditions of Physical extents.

Thanks,
Vivek

Re: vgreduce fails .. physical extents are still in use

Eric SAUBIGNAC — Thu, 07 Feb 2008 09:45:20 GMT

Bonjour,

I do agree with TTr (and with his personnal quote ;-) : there is a strong chance that the stale extent resides on the disk which has not been replaced.

That could also mean that when the disk was failed you had a stale extent on the survival one. So there is a chance that some datas are damaged or, worst, the FS itself. IMHO you must rebuild the FS if you don't want any bad surprise in the future.

Before any action you should first have a map of stale extents in all LV of appsvg00. No need to use -k option. You could do something like :

find /dev/appsvg00 -type b | while read LV
do echo
echo "-------- $LV"
lvdisplay -v $LV | egrep -i stale
done

Post the result

Regards

Eric