What does "Bad MCR, resyncing all LVs on the PV" mean?

[brent clements]

I'm getting the following in my dmesg:

LVM: vg[1] pv[0] Bad MCR, resyncing all LVs on the PV
LVM: vg[1] pv[1] Bad MCR, resyncing all LVs on the PV
LVM: vg[2] pv[0] Bad MCR, resyncing all LVs on the PV
LVM: vg[2] pv[1] Bad MCR, resyncing all LVs on the PV

I think it's related to another problem I'm having which is that all of my clients keep on reporting that the NFS fileserver(this hpux box) is timing out.

Thanks for any help!

-Brent

[Prashant Zanwar_4]

This is the Mirror consistency record which is bad on few PV's on your system. It may or may not be dangerous.

Dangerous : If the PV is failing
Non-Dangerous : If it is just to resync the LV's on your PV after some change to the system.

you may try finding out which Lvol's have this problem and figure our accordingly:

lvdisplay -v /dev/vg*/lvol[0-9] | grep -i stale | more

Try doing a manual lvsync or vgsync on the VG in question...

Hope this helps..
And also please summerize how to you rectify this..

Thanks
Prashant

[Cheryl Griffin]

Have you run vgcfgrestore recently?

You need to make sure that you have applied the LVM cumulative patch for your operating system level. There were changes to how the MCR record is used.
PHKL_30553 11.00 LVM Cumulative Patch
PHKL_30622 11.11 LVM Cumulative Patch

Run a vgdisplay -v on the volume groups to make sure that the vg is not showing any problems.

[brent clements]

Well now this is what I am getting...what does it mean?

SCSI: Read error -- dev: b 31 0x050400, errno: 126, resid: 1024,
blkno: 8, sectno: 16, offset: 8192, bcount: 1024.
LVM: Performed a switch for Lun ID = 0 (pv = 0xe00000014da1e000), from raw device 0x1f050400 (with priority: 0, and current flags: 0x40) to raw device 0x1f080400 (with priority: 1, and current flags: 0x0).
LVM: VG 64 0x20000: PVLink 31 0x50400 Failed!. The PV is still accessible.
LVM: VG 64 0x20000: PVLink 31 0x50400 Recovered.
LVM: Performed a switch for Lun ID = 0 (pv = 0xe00000014da1e000), from raw device 0x1f080400 (with priority: 1, and current flags: 0x0) to raw device 0x1f050400 (with priority: 0, and current flags: 0x0).
LVM: Performed a switch for Lun ID = 0 (pv = 0xe00000014da1e000), from raw device 0x1f050400 (with priority: 0, and current flags: 0x40) to raw device 0x1f080400 (with priority: 1, and current flags: 0x0).
LVM: VG 64 0x20000: PVLink 31 0x50400 Failed!. The PV is still accessible.
LVM: Performed a switch for Lun ID = 0 (pv = 0xe00000014da1e000), from raw device 0x1f080400 (with priority: 1, and current flags: 0x0) to raw device 0x1f050400 (with priority: 0, and current flags: 0x80).
LVM: VG 64 0x20000: PVLink 31 0x50400 Recovered.

Thanks,
Brent

[Jannik]

It looks like you have a failed disk!
ioscan -funC disk
to see if all you disks are claimed if NO_HW you call HP to come and change the disk.

If you do it yourself.
change the disk and the:
ioscan -f /dev/dsk/cXtXdX
vgcfgrestore -n VG /dev/rdsk/cXtXdX

vgchange -a y vgXX
or
vgchange -a e vgXX (cluster)

If it is a root disk you need to do this as well:
mkboot -l /dev/rdsk/cXtXdX
lifls â l /dev/rdsk/cXtXdX
mkboot -a hpux /dev/rdsk/cXtXdX
or
mkboot -a â hpux â lqâ /dev/rdsk/cXtXdX
lifcp /dev/rdsk/cXtXdX:AUTO

vgsync vgXY &
To check the progress of the synchronization you could use:
lvdisplay -v $(find /dev/vgXY -type b) | grep stale | wc -l

If the disk is claimed then look for staled PE in you lv's:
lvdisplay -v | grep -i stale
and is otherwise ok you could a:
vgsync vgXY &

LOOK AT THIS LINK:
http://www2.itrc.hp.com/service/iv/node.do?node=prodITRC%2FWW_Start%2F