reducing rootvg

[aaronkeith]

Hi!

I need your help. I have extended my rootvg and made use of an EMC disk as the additional disk. This EMC disk contains additional partitions of /tmp. Now, I found out that the said EMC disk is not a bootable disk and when I issue the command lsvg -p rootvg has the output below:

rootvg:
PV_NAME PV STATE TOTAL PPs FREE PPs FREE DISTRIBUTION
hdisk0 active 542 0 00..00..00..00..00
hdisk21 missing 539 531 108..108..99..108..108

Hdisk21 is in missing state. Now, I am having problem with hdisk0 and have asked IBM to replaced the disk. Unfortunately, I can not restore my mksysb and I am encountering a syntax error. This might be because of the EMC disk. Is there a way for me to remove the EMC disk from rootvg? But how can I do this if I can not unmount /tmp? Is there a way for me to reduce /tmp?

i badly need your help because my hdisk0 might crash any time soon.

Thanks,
aaronkeith

 

[plamb]

did some remove the emc disk from zoning?? if so rezone it the si it is no longer missing. then reduce vg then rmdev the disk. Why do you say it is not bootable??? I have many emc boot disks.

 

[p5wizard]

hdisk21 doesn't even have to be bootable if hdisk0 is your boot disk. Just needs to be 'available' at boot time when the system runs ipl_varyon.

I suspect hdisk21 is dome sort of multipathing disk device and maybe at boot time you cannot use your MP software yet.

If hdisk21 is available now, just run

varyonvg rootvg

manually to get the hdisk21 from "missing" to "active".

You will have to free some space on hdisk0 and move the 8 PPs from hdisk21 back to hdisk0 or extendvg rootvg with another disk and

migratepv hdisk21 hdiskX

This is assuming you still have a system. What do you mean by
> I can not restore my mksysb...
?

 

[plamb]

it has been a know isue when you have both an internal disk and external san disk in rootvg. I do have emc san disks as bootable rootvg.

 

[aaronkeith]

I am trying to restore mksysb using tape. I have encountered a syntax error.

p5wizard and plamb: Thanks for the inputs. By the way how can I put back the 8 PPs back to hdisk0. what would be the procedure to do it considering its /tmp filesystem?

My OS is 4.3.3.

Thanks,
Liza

 

[p5wizard]

Can you post the output of

lsvg -l rootvg

that could be helpful in pointing you in the right direction..

If you can get rid of another FS/LV in rootvg (move it out to another VolumeGroup for instance)?

...then (with at least 8 PPs free in hdisk0)

migratepv hdisk21 hdisk0

But PV hdisk21 has to be "active" again for this first (see previous post)

OR

use the procedure for shrinking rootvg filesystems - but as this is based on doing an install of a specially modified mksysb I guess that is not an option since you run into a problem while trying to restore your mksysb??

 

[aaronkeith]

this is the output of lsvg -l rootvg

rootvg:
LV NAME TYPE LPs PPs PVs LV STATE MOUNT POINT
hd5 boot 1 1 1 closed/syncd N/A
hd6 paging 32 32 1 open/syncd N/A
hd8 jfslog 1 1 1 open/syncd N/A
hd4 jfs 4 4 1 open/syncd /
hd2 jfs 116 116 1 open/syncd /usr
hd9var jfs 27 27 1 open/syncd /var
hd3 jfs 57 57 2 open/syncd /tmp
home jfs 175 175 1 open/syncd /home
lv00 jfs 128 128 1 open/syncd /area1b
fcss jfs 3 3 1 closed/syncd N/A
hd7 jfs 6 6 1 closed/syncd N/A

I can not move /tmp to another VG because it is being used everytime.

Thanks,
Liza

 

[p5wizard]

The only candidate I see is /area1b, but you may require some downtime for this

also your /home is fairly large, consider this

df /home
cd /home
du -ks *|sort -n

The directories that consume most diskspace will be at the bottom of the list. You may want to create a separate filesystem in another VG for one or more of the directories (total at least 64MB - assuming 8MB PP size)

(If df shows enough free space for /home you may not even have to isolate one or more dirs in their separate FSs, just make a new /dev/hd1 /home FS that is at least 8PPs smaller)

Then make a secure backup of /home, remove /home, make a new lv hd1 in rootvg on hdisk0 with 167 PPs or less and make a new /home FS on hd1 and mount it, then make your /home/whatever FS (or more than one) in different VGs
and mount those also. Then restore your /home backup and you should have at least 8 PPs free on hdisk0 for your migratepv

Note: you can do this on hd1 (/home) when it is not being used so also user/application downtime...
You can't do this for hd3 (/tmp) because the some OS daemons - cron for one- have it in use.

Also stick to the hd numbers when re-creating rootvg FSs!

ANOTHER OPTION:

LV fcss is not being used? maybe you can delete it (3 PPs already).
Also, hd7 (dumplv) is not being used - I also believe that it is way too small anyway)

if

sysdumpdev

shows that you do not use /dev/hd7 then that's another 6 PPs if you delete it
Of course not having a dump device makes life harder for you when you encounter a serious problem and do not have a dump to send to IBM. But as I said 6 PPs is maybe not enough anyway.

sysdumpdev -e

will estimate the space needed for your dumps

 

[aaronkeith]

Thanks! I got your point but /tmp is the one extended on hdisk21. That is the biggest problem, I can not reduce the size of the LV so as to confine it only on hdisk0.

Would it help if I make a fresh mksysb and set shrink filesystem parameter to yes? then I will try to restore it to another server and once restored, I will create a mksysb again.

thanks again for all your effort to help.

 

[p5wizard]

It doesn't matter what LV is now on hdisk21, if you make room for the 8 PPs on hdisk0, you can migrate the /tmp PPs from hdisk21 to hdisk0.

Given the info (lsvg -l) and the "unused" LVs that are present, you can even do it without downtime if you give up the LVs fcss and hd7.

LVM migratepv doesn't care what data was once on a PP, if it is unallocated, then it can be used again for a different purpose.


HTH,

p5wizard

 

[mrn]

Take a look at

http://www.compunix.com/prod/reduce.vs

Mike

"A foolproof method for sculpting an elephant: first, get a huge block of marble, then you chip away everything that doesn't look like an elephant.