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

[Sandman!]

The upto date state of the vg00.conf file does not matter as long as they contain the PVs that make it up including the bad one. Simply replace the bad PV mirror vg00 and you should be all set.

~cheers

[ricardor_1]

Thank you. I was able to remove the disk. vgcfgbackup did not work, I had to vgreduce it and reconstruct the mirror by lvextending each of the lvols again.

I still have a problem though. The lvols pertaining to / and /var do not sync one PE each one. It complains of I/O error, which I suspect is rather a data corruption problem than a physical compromise of the first HDD.

How can I solve that problem considering it´s the root filesystem that does not resync? I though of:

- booting in single user,
- creating a new lvol, copying / with tar
- exclude, piping to a tar extracting to a the new /,
- updating fstab on both lvols
- running lvlnboot updating the root lvol and then rebooting to multiuser again.

the same to the /var lvol.

Any other suggestions? Should this work?

[Mridul Shrivastava]

This will not work since it is a root filesystem.

You have to take backup using ignite ie make_tape_recovery if you have tape drive connected to the system. Then restore it. But do you really think if there is data corruption this will sove the issue ?? Since you will be restoring the same data back to the system ??

Rather I would suggest to restore the old backup if you have any?

One way to confirm the bad block would be to run read test using dd command. or you could check the same in cstm.

[ricardor_1]

Thank you for the tips. Actually I *think* it might be a data corruption problem because the "I/O error" mirrordisk complains of does not generate any hardware messages/kernel information.

Doing a make_net|tape_recovery would confirm if there´s any data loss, in the case there´s data on the stale PEs.

Our recovery tapes are rather outdated (~ 8 months) so I will probably try to restore a new recovery image. If it doesn´t work, then I´ll try the old ones.

Thank you again. If anyone has any other comments, I would like them to hear from you.

[Ben Dehner]

This is an old thread, but I had the same problem.  A failed disk in my mirrored root volume group.  'lvreduce' would hang, 'vgreduce', depending on the option, either did nothing or errored out with 'extents in use', and 'pvchange -a n' also did nothing useful.

Finally, I found the following approached worked:

important step:  first pull the bad disk and replace it with a working disk

now remove mirrors off of the bad path -- it will complain about 'invalid physical volume', but it won't hang on SCSI errors from the failed device.

lvreduce -m 0 <DISK_PATH>

pull the disk from the volume group

vgreduce vg00 <DISK_PATH>

create a physical volume on the replaced disk.  ( -B since this is a boot disk).

pvcreate -B <RDISK_PATH>

make the disk bootable 

mkboot <RDISK_PATH>

mkboot -a "hpux" <RDISK_PATH>

add the disk back to our volume group

vgextend vg00 <DISK_PATH>

re-establish mirroring for all LV's in the volume group

lvextend -m 1 /dev/vg00/lvolNN <DISK_PATH>

vgcfgrestore may perform many of the same steps.   I am not an LVM expert, but my primary concerns were that, since this disk is part of my root volume group, i) the disk had to be bootable with the LIF partition, and ii) as part of the root volume, the logical volumes had to exist *in the proper order* on the replaced disk if the system used this as the boot device.  Given my unfamliarity with LVM, I performed the manual steps that I knew would do what I needed.