- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - HP-UX
- >
- Re: vgreduce fails .. physical extents are still i...
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
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
тАО02-06-2008 07:59 AM
тАО02-06-2008 07:59 AM
vgreduce: Physical volume "/dev/dsk/c6t0d0" could not be removed since some of its
physical extents are still in use.
I have tried to reduce using pk keys and no luck.
# lvreduce -k -m 0 /dev/appsvg00/lvvartibco 1
lvreduce: Couldn't reduce the logical volume:
Device busy
lvreduce: The LVM device driver failed to reduce mirrors on
the logical volume "/dev/appsvg00/lvvartibco".
I found a document with the error but the doc states that the reason for the error is that the lv device files are missing. In this case they are not missing.
the vg does have one stale extent.
Thanks !
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-06-2008 08:04 AM
тАО02-06-2008 08:04 AM
Re: vgreduce fails .. physical extents are still in use
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-06-2008 08:06 AM
тАО02-06-2008 08:06 AM
Re: vgreduce fails .. physical extents are still in use
Stale extents indicate that something has gone wrong. A disk or mirror has failed.
Ideas to get the vgreduce to work.
1) Remove associated logical volumes (lvremove)
Obviously back up the data first and umount any filesystems.
2) vgreduce -f (follow the instructions afterward. This is a relatively dangerous thing to do, but sometimes you have to do it.
SEP
Owner of ISN Corporation
http://isnamerica.com
http://hpuxconsulting.com
Sponsor: http://hpux.ws
Twitter: http://twitter.com/hpuxlinux
Founder http://newdatacloud.com
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-06-2008 10:15 AM
тАО02-06-2008 10:15 AM
Re: vgreduce fails .. physical extents are still in use
You said "Trying to reduce a disk out of a mirrored vg."
--> Why do you want to do that ? If the disk is out work, HP is supposed to change it ASAP. There is no need to unmirror the LVs. The procedure is rather simple and can be done online. Here is the general guideline : change the failed disk, ioscan, vgcfgrestore on the new disk, reactivate the vg, then vgsync if necessary.
Anyway, you may still want to unmirror, just because your maintenance contract is expired or anything eles ...
So why "lvreduce -k ... 1" and not "lvreduce -k ... 0" ? I mean have you localized on which disk there is "one stale extent" ? (if the disk is really HS, you may have now more than just one stale extent).
Could you control output of "lvdisplay -k -v dev/appsvg00/lvvartibco | egrep -i stale". Is it really on pvkey 1 and always on the same pvkey ? You should also control all LV on this VG.
Knowing that it will be easier to give valuable advice.
Regards
Eric
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-06-2008 11:08 AM
тАО02-06-2008 11:08 AM
Re: vgreduce fails .. physical extents are still in use
ran vgcfgrestore to restore ..
After everything synced up I still had one bad stale extent.
I was going to break the mirror and re-mirror.
All of the lv's where fine until I got to the one that had one stale extent. When I tried to break it was when I got the error ..
# lvreduce -m 0 -A n /dev/appsvg00/lvvartibco /dev/dsk/c6t0d0
lvreduce: Couldn't reduce the logical volume:
Device busy
lvreduce: The LVM device driver failed to reduce mirrors on
the logical volume "/dev/appsvg00/lvvartibco".
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-06-2008 12:41 PM
тАО02-06-2008 12:41 PM
SolutionUnder this assumption (bad PE on the first disk) you can do the following
Run a read test on the first disk using the dd command.
You don't see any file read errors because by luck that extend has no data in it.
You need to create anothr LV and move the tibco volume to this new LV and delete the old LV altogether.
pvmove may be an option here if you have another disk to use temporarily.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-06-2008 02:01 PM
тАО02-06-2008 02:01 PM
Re: vgreduce fails .. physical extents are still in use
Check the lvdisplay output, it will show you the conditions of Physical extents.
Thanks,
Vivek
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-07-2008 01:45 AM
тАО02-07-2008 01:45 AM
Re: vgreduce fails .. physical extents are still in use
I do agree with TTr (and with his personnal quote ;-) : there is a strong chance that the stale extent resides on the disk which has not been replaced.
That could also mean that when the disk was failed you had a stale extent on the survival one. So there is a chance that some datas are damaged or, worst, the FS itself. IMHO you must rebuild the FS if you don't want any bad surprise in the future.
Before any action you should first have a map of stale extents in all LV of appsvg00. No need to use -k option. You could do something like :
find /dev/appsvg00 -type b | while read LV
do echo
echo "-------- $LV"
lvdisplay -v $LV | egrep -i stale
done
Post the result
Regards
Eric