- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - HP-UX
- >
- stale extents on mirror
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-06-2003 10:25 AM
тАО06-06-2003 10:25 AM
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?
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-06-2003 10:29 AM
тАО06-06-2003 10:29 AM
SolutionYou 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..
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-06-2003 10:36 AM
тАО06-06-2003 10:36 AM
Re: stale extents on mirror
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-06-2003 10:43 AM
тАО06-06-2003 10:43 AM
Re: stale extents on mirror
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-06-2003 10:43 AM
тАО06-06-2003 10:43 AM
Re: stale extents on mirror
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-06-2003 11:11 AM
тАО06-06-2003 11:11 AM
Re: stale extents on mirror
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-06-2003 11:16 AM
тАО06-06-2003 11:16 AM
Re: stale extents on mirror
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-06-2003 11:22 AM
тАО06-06-2003 11:22 AM
Re: stale extents on mirror
I haven't shut down a box for a disk replacement in well over five years.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-06-2003 11:30 AM
тАО06-06-2003 11:30 AM
Re: stale extents on mirror
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-06-2003 11:36 AM
тАО06-06-2003 11:36 AM
Re: stale extents on mirror
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.)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-06-2003 11:44 AM
тАО06-06-2003 11:44 AM
Re: stale extents on mirror
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