1819712 Members
2886 Online
109605 Solutions
New Discussion юеВ

stale extents on mirror

 
SOLVED
Go to solution
Todd McDaniel_1
Honored Contributor

stale extents on mirror

i just wanted to verify my concerns.

I have a mirror that is failing. It has to LVs on it that I have unmounted already.

I have done a:

Lvdisplay ???v ???k /dev/vg01/crash (to find out mirror PV number) Which in my case is 3.

chpcfas3-root:/root
# lvdisplay -v -k /dev/vg01/crash|pg
--- Logical volumes ---
LV Name /dev/vg01/crash
VG Name /dev/vg01
LV Permission read/write
LV Status available/stale
Mirror copies 1
Consistency Recovery MWC
Schedule parallel
LV Size (Mbytes) 4000
Current LE 1000
Allocated PE 2000
Stripes 0
Stripe Size (Kbytes) 0
Bad block on
Allocation strict
IO Timeout (Seconds) default
PV Name LE on PV PE on PV
--- Distribution of logical volume ---
PV Name LE on PV PE on PV
/dev/dsk/c3t4d0 1000 1000
/dev/dsk/c4t4d0 1000 1000
--- Logical extents ---
LE PV1 PE1 Status 1 PV2 PE2 Status 2
00000 2 00500 current 3 00500 stale
00001 2 00501 current 3 00501 current
00002 2 00502 current 3 00502 current

that gives me the PV number to use for lvreduce right?

Lvreduce ???m 3 /dev/vg01/crash /devdsk/c4t4d0
lvreduce -m /dev/vg01/openveritas /dev/dsk/c4t4d0

So I can then change out the bad disk and replace it. then do my:

1) vgcfgrestore -n vg01 /dev/rdsk/c4t4d0

2) vgchange -a y /dev/vg01

3) vgsync vg01



OR my other question is this. Can I just shutdown the box and then replace teh disk and reboot sinc it is a mirror? And it will come up on its own upon reboot?
Unix, the other white meat.
10 REPLIES 10
Marco Santerre
Honored Contributor
Solution

Re: stale extents on mirror

Hi Todd,

You are better off shutting down the server and then replacing the disk and following the procedure that you can find in the ITRC Knowledge Base # KBAN00000347

Follow the procedure for mirrored disk..
Cooperation is doing with a smile what you have to do anyhow.
S.K. Chan
Honored Contributor

Re: stale extents on mirror

There are 2 ways of doing this ..
1) Without lvreduce.
2) With lvreduce.
You seem to want method 2) which is fine if you want to lvreduce the mirror copy first BUT you do not have to. The normal process is (ie method 1) , after you've confirmed which mirrored disk to replaced, shutdown your machine, replace your disk (keep scsi id the same), boot the machine up in single user mode.
ISL> hpux -is (;0)/stand/vmunix
# ioscan -fnC disk
==> Check to make sure the new disk is claimed.
# pvcreate -f /dev/rdsk/c4t4d0
# vgcfgrestore -n /dev/vg01 /dev/rdsk/c4t4d0
# vgchange -a y /dev/vg01
# vgsync /dev/vg01
# shutdown -r 0

To answer you question on lvreducing with the key value .. the right syntax is ..
# lvreduce -m 0 -k /dev/vg01/crash 3
# lvreduce -m 0 -k /dev/vg01/openveritas 3
That is the key value goes to the end of the lvreduce command.


Todd McDaniel_1
Honored Contributor

Re: stale extents on mirror

Thanks guys. If I need to, I think I will do what SK Chan has suggested that sounds good.

The disk was in the process of dying the last 2 days. I think it is now actually dead...

However, I say "if I need to" B/c I get nothing back from diskinfo except for an error message. We may go ahead and just replace the disk online since it looks totally dead now. I will verify with my CE before we do that though.

thanks again.
Unix, the other white meat.
Todd McDaniel_1
Honored Contributor

Re: stale extents on mirror

Thanks guys. If I need to, I think I will do what SK Chan has suggested that sounds good.

The disk was in the process of dying the last 2 days. I think it is now actually dead...

However, I say "if I need to" B/c I get nothing back from diskinfo except for an error message. We may go ahead and just replace the disk online since it looks totally dead now. I will verify with my CE before we do that though.

thanks again.
Unix, the other white meat.
Sridhar Bhaskarla
Honored Contributor

Re: stale extents on mirror

Hi,

Few precautions

1. If your autoboot flag is not set to "hpux -lq", then you will have to interact with ISL and boot with "hpux -lq". Verify it using the command

lifcp /dev/dsk/c6t0d0:AUTO -

2. You will still need to run mkboot commands after or before vgcfgrestore.

vgcfgrestore -n vg00 /dev/rdsk/c6t0d0
vgchange -a y vg00
mkboot -l /dev/rdsk/c6t0d0
mkboot -a "hpux -lq" /dev/rdsk/c6t0d0
cd /usr/sbin/diag/lif
mkboot -vb updatediaglif2 -p ISL -p AUTO -p HPUX /dev/rdsk/c6t0d0
lvlnboot -b /dev/vg00/lvol1
lvlnboot -s /dev/vg00/lvol2
lvlnboot -r /dev/vg00/lvol3
lvlnboot -d /dev/vg00/lvol2
lvlnboot -R
vgsync

-Sri
You may be disappointed if you fail, but you are doomed if you don't try
Patrick Wallek
Honored Contributor

Re: stale extents on mirror

Just a word on Sridhars procedure... That is ONLY if you are replacing a VG00 boot disk, which you are not. For VG01 you do not need to worry about 'pvcreate -B', the mkboot statements or the lvlnboot statements.
A. Clay Stephenson
Acclaimed Contributor

Re: stale extents on mirror

If this is a hot-plug drive then there is no need to even shutdown. Just pull the bad drive, pop in the new one, and start at the vgcfgrestore.

I haven't shut down a box for a disk replacement in well over five years.
If it ain't broke, I can fix that.
Sridhar Bhaskarla
Honored Contributor

Re: stale extents on mirror

Hi,

Yes. Patrick is right. I somehow read it like vg00 mirror disk replacement procedure. Please discard my message.

Thanks Patrick for waking me up from the day dreams.

-Sri
You may be disappointed if you fail, but you are doomed if you don't try
Patrick Wallek
Honored Contributor

Re: stale extents on mirror

Sridhar,

No problem. You are entitled to day dreams. After all it is Friday and you do have to put up with Jeff on a day-to-day basis.

(Sorry Jeff, I couldn't resist.)
Todd McDaniel_1
Honored Contributor

Re: stale extents on mirror

Thanks. yea, it was a VG01 not a root disk.

It was dead so we did an online replacement.

My only concern and the reason for my original Question would have been if it were a failing disk as opposed to a dead disk.

I replace dead disks all the time without reboooting only doing:

1) vgcfgrestore -n vg01 /dev/rdsk/c4t4d0
2) vgchange -a y /dev/vg01
3) vgsync vg01
Unix, the other white meat.