Stlale extents

[Eric Bradley]

The primary vg00 PV is taking errors. Due to read errors on some extents during syncing to the mirror PV, the mirror is showing stale rather than current on those extents in lvol7 (/usr). Result: I have a Primary vg00 PV going bad at the hardware level and the good mirror PV showing stale extents. Cannont lvreduce - it fails. I haven't tried getting the disk key and reducing that way, but if I do I'm afraid /usr will be corrupt with some stale extents on the mirror disk. Any suggestions to fix this problem and replace the Primary PV withou an outage? They are hot swap internal drives.

[Geoff Wild]

How about add a third disk and mirror to it?

Rgds...Geoff

[Lolupee]

Eric,

this error could be tricky. Please, run

dd if=/dev/dsk/cXtXdX of=/dev/null bs=128k

on each of the drives and see if any would give error to confirm which disk is actualy defective. We would then workmm on the defective drive.

You can reduce the bs size if there is no error.
Hope you have tried to re-sync the drives before all these.

lvsync /dev/vg00/lvol7

[Eric Bradley]

Both lvsync and lvreduce fail. The dd on the Primary disk (c2t6d0) has errors and is reporting incidents to ISEE. The dd on the mirror disk (c0t6d0) passes. The lvsync fails because c2t6d0 has 2 bad extents which are taking read errors resulting in the matching extents showing stale on c0t6d0. I can't mirror to a third disk because I have unreadable and stale extents on both of the current disks so I have nothing to mirror from. I have considered using lvreduce -m -k disk_key# but I'm not sure how the system would react to having /usr running on a disk with 2 stale extents. Any ideas?

[Lolupee]

It is confirmed that the Primary disk is the bad disk and it could be physically removed by HP CE.

The next step is. Do you have a good lvmconf file?.

check the /etc/lvmconf/vg00 and confirm that the file is a good one. Are we discusing on RISC server or Itanium.

[Eric Bradley]

Itanium, rx8602. My concern with replacing the bad disk is that I won't be able to sync back to the new one from the current mirror since there are 2 stale extents on the mirror. Not sure how to get past that - maybe replace the bad disk and then recover /usr to the mirror disk from a backup to get rid of the stale extents, then vgcfgrestore, vgchange -a y, and vgsync. Any ideas on that one?

[rariasn]

Hi Eric,
Trie this,

pvchange -A n -an /dev/dsk/cxtydz /dev/vg00
Change disk and,

pvchange -a y /dev/dsk/cxtydz /dev/vg00

vgchange -a y vg00

[Devender Khatana]

Hi,

I would suggest to physically remove the device after shutdown and then try booting through the disk having only 2 stale PE's. This should not give any problem if the LVOLs are quite free, and if it gives errors you will have to recover /usr from a good backup.

I do not think you can avaoid a outage here, as even if you replace the disk and resync you cannot conform functionality without booting from both disks indivisually.

Here is the official disk replacement guide
http://docs.hp.com/en/5991-1236/When_Good_Disks_Go_Bad.pdf

HTH,
Devender

[RAC_1]

I would boot from mirror disk and take primary out. If everything goes well with boot from mirror disk, replace primery and re-mirror.

[Steve Faidley]

What came of this?
It would be good to hear the steps taken.
My thoughts are to setup a PVG including the mirror disk and do an lvplit to get /usr only on primary disk. then try to mirror back to the "mirror" disk. If that works then you should follow normal procedures for replacing a a vg00 disk. If it still fails due to the 2 bad extents you could try to cheat if you have at least 2 extents available.
1. create a dummy lvol up to those bad extents
2. create a 2nd dummy lvol on those 2 extents.
3. lvremove the 1st dummy lvol
4. mirror /usr to the "mirror" disk.

If the 2 disks were not configured corrctly ( mirror disk was not properly configured to boot off of) in the first place then all bets are off.