MirrorDisk/UX: lvreduce hangs while attempting to remove failed disk.

[ricardor_1]

Hi there,

I´ve got a bad disk which is not in the NO_HW state. Most of the PEs are stale. We cannot reboot that machine now, so we chose to lvreduce each of the local filesystems so we can remove the disk and rsync the mirror.

We do not have the pvchange -a n patches.

When running lvreduce -m 0 /dev/vg00/lvolX /dev/dsk/ it returns the LV was successfuly reduced (and lvdisplay confirms that), but it hangs after some lvlnboot: Logical Volume has no extents.

What should be done? the syslog keeps throwing scsi errors...

Thank you.

[Sandman!]

What is the server model and what version of HPUX is it running and which command's hanging lvreduce or lvlnboot? Post the output of strings /etc/lvmtab and force out the bad PV by doing vgreduce -f vg00.

~cheers

[Ramesh S · Accepted solution]

Hi

Please post your strings /etc/lvmtab output and vgdisplay vg00 output.

As Sandman mentioned, try to pull out the PV from VG00 by "vgreduce -l -f vg00" and run "lvlnboot -R"

Thanks & Regards

Ramesh

[Mike Shilladay]

Hi Ricardor,

You could always try the lvreduce command with the 'k' switch.

For example to remove the extents on a specific disk, (in my example c5t0d0) you would use the command

# lvreduce -m 0 -k /dev/vg00/lvol5 /dev/dsk/c5t0d0

You will need to do this on all the logical volumes in the volume group and then remove from the disk from the volume group with the vgreduce command. You may need to force it with the f option as mentioned in previous post.

Hope that helps,

Mike.

[ricardor_1]

We're running 11.11. ps shows it' s actually the lvreduce command that hangs.

lvreduce -m 0 -k /dev/vg00/lvolX /dev/dsk/

fails complaining that the remaining disks do not have too the PEs to that LVOL, which is odd, since all the extents are current within the remaining PV.

I was able to kill -9 it, but it only returns after some 30-40 minutes. I suspect it might be the vgcfgbackup after the lvreduce that' s hanging? What about the -A n switch?

The overall procedure I'm trying is:

- vgexporting (preview mode) other VGs.
- lvreduceing all the filesystems on the mirror set
- vgreduceing the faulty PV with -f
- Remove the deffective HD
- Wait for NO_HW, then insert the new HD
- The bootsectors
- create the PV
- vgextend
- lvextend recreating the mirror.

I'm currently stuck at the second step... Any suggestions/corrections?

Thank you.

[ricardor_1]

The vgdisplay -v output (some LVs removed to save space..)

--- Volume groups ---
VG Name /dev/vg00
VG Write Access read/write
VG Status available
Max LV 255
Cur LV 11
Open LV 11
Max PV 16
Cur PV 2
Act PV 2
Max PE per PV 4384
VGDA 4
PE Size (Mbytes) 16
Total PE 8748
Alloc PE 7994
Free PE 754
Total PVG 0
Total Spare PVs 0
Total Spare PVs in use 0

--- Logical volumes ---
LV Name /dev/vg00/lvol1
LV Status available/stale
LV Size (Mbytes) 1024
Current LE 64
Allocated PE 128
Used PV 2

(many other LVs, all stale... the following was the one I was able to lvreduce, but only after waiting 40 minutes the lvreduce command (being killed -9) returned).

LV Name /dev/vg00/lvol13
LV Status available/syncd
LV Size (Mbytes) 10304
Current LE 644
Allocated PE 644
Used PV 1


--- Physical volumes ---
PV Name /dev/dsk/c2t0d0
PV Status available
Total PE 4374
Free PE 23
Autoswitch On

PV Name /dev/dsk/c2t1d0
PV Status unavailable
Total PE 4374
Free PE 731
Autoswitch On



The c2t2d0 HD is CLAIMED.

The meaning part of lvmtab:
/dev/vg00
/dev/dsk/c2t0d0
/dev/dsk/c2t1d0

[TwoProc]

Don't reduce it. Just replace the disk with the new one and run vgcfgrestore to the replaced disk, and then use vgsync.

This way, you won't get hung with this whole process.

[likid0]

Thats true, there is no need to take the disk out of the vg00, you can just swap the disk, and then restore the lvm header with the vgcfgrestore command.

If you want to reduce a disk that is not present on the system you need to use the -k option:

If the disk was not available at boot time (pvdisplay failed) then the lvreduce command fails with an error that it could not query the physical volume. You can still remove the mirror copy, but you must specify the physical volume key rather than the name. You can get the key using lvdisplay with the â k option as follows: # lvdisplay -v â k /dev/vg00/lvol1 â ¦ --- Logical extents --- LE PV1 PE1 Status 1 PV2 PE2 Status 2 00000 0 00000 stale 1 00000 current 00001 0 00001 stale 1 00001 current 00002 0 00002 stale 1 00002 current 00003 0 00003 stale 1 00003 current 00004 0 00004 stale 1 00004 current 00005 0 00005 stale 1 00005 current â ¦ Compare this output with the output of lvdisplay without â k, which you did to check the mirror status. The column that contained the failing disk (or â ???â ) now holds the key. For this example, the key is 0. Use this key with lvreduce as follows: # lvreduce -m 0 -A n â k /dev/vgname/lvname key (if you have a single mirror copy) or # lvreduce -m 1 -A n â k /dev/vgname/lvname key (if you have two mirror copies)

[likid0]

sorry fot that, you can't read anything:

If the disk was not available at boot time (pvdisplay failed) then the lvreduce command fails with an error that it could not query the physical volume. You can still remove the mirror copy, but you must specify the physical volume key rather than the name. You can get the key using lvdisplay with the â k option as follows:

# lvdisplay -v â k /dev/vg00/lvol1


Compare this output with the output of lvdisplay without â k, which you did to check the mirror status. The column that contained the failing disk (or â ???â ) now holds the key. For this example, the key is 0. Use this key with lvreduce as follows:


# lvreduce -m 0 -A n â k /dev/vgname/lvname key (if you have a single mirror copy)
# lvreduce -m 1 -A n â k /dev/vgname/lvname key (if you have two mirror copies)

[ricardor_1]

Hi,

Thank you all for your valuable tips, but I still have a question.

Since I tried to lvreduce some of the lvols, and also vgcfgbackup has failed due to the bad HD (it did not execute, at least no successful backup message was returned), what is the state of the .conf files that'll be used for the restore? It's probably not up to date, right?