How to hot resize a filesystem
ienet
Being a newbie, I have a very noob question to ask about AIX5.3
At my company, we have to resize a partition mounted from a Storage
Area Network which is a RS4500 Array of RAID 5 redundant disks. I do
not have the skills to do this on my own.
We could go through resizing the volume form the FAST900 console which
said it was successfully done.
Though, from my tty, I can't see the partition size updated, which is
still used at 99%, becoming very critical for the database runnning
core business jobs.
Here what I get when issuing lsvg
[root@p5_dev /]# lsvg -l vg-dev-sbl
vg-dev-sbl:
LV NAME TYPE LPs PPs PVs LV STATE MOUNT
POINT
sbl_lv jfs2 158 158 1 open/syncd /siebel
loglv00 jfs2log 1 1 1 open/syncd N/A
And here lspv's output
[root@p5_dev /]# lspv
hdisk9 00c4c08ebffb2f80 vg-dev-inf
active
hdisk11 00c4c08ebffb3653 vg-tools
active
hdisk12 00c4c08ebffb39c5 vg-webm-is
active
hdisk13 00c4c08ebffb28a8 vg-dev-gcp
active
hdisk14 00c4c08ebffb440a rootvg
active
hdisk15 00c4c08ebffb32e7 vg-dev-sbl
active
Since we have a database running on that filesystem, we cannot afford
unmount/mount the filesystem.
Does anyone have a solution for this annoying problem ?
thanks in advance
med
Grateful for any piece of help
Pete's
I do not have experience with FastT but guessing it's similar in
nature to NetApp. You can resize the LUN on the fastt, but AIX is not
going to pick it up as the hdisk is already in the system with the
size information. I'm not sure what affect it would have if you
deleted the hdisk from the odm and then re-added it w/ cfgmgr, I would
not recommend this. All is not lost thought, I suggest sizing your
lun back down to its original size, then create a new lun and attach
it to the system. Then, run cfgmgr, it should come in as another
hdisk. Add that hdisk to the volume group, then extend the logical
volume onto the new hdisk and then finally extend the file system.
HTH,
Pete's
smallpond
Does this do what you want?
chvg -g VGname
ienet
man chvg requires issuing varyoffvg, varyonvg on the volume group
before chvg -g VGname.
Does this implicate the volume group (and then the partition) is going
offline ?
thanks for your help
Pete's
> man chvg requires issuing varyoffvg, varyonvg on the volume group
> before chvg -g VGname.
> Does this implicate the volume group (and then the partition) is going
> offline ?
>
> thanks for your help
The man page is stating that 'You may be required to issue a varyoffvg
and then a varyonvg before issuing a "chvg -g vgname" before the size
change is recognized. So in essence, yes the volume group would need
to be taken offline. If as you state that you can not take some
downtime, my suggestion above still holds and will work.
HTH,
Pete's
pinoy2ser
i have done this in the past.. i did not have to vary off the volume
group however, we
had to stop the database..
1)after you execute # chvg -g VGname
2)you may have to update the LV and give it more logical partitions..i
usually use 4000 to be safe
MAXIMUM NUMBER of LOGICAL PARTITIONS [512]
3) extend you filesystem
chfs -a size=+8192 /FILESYSTEM
ienet
ok, me and my colleagues decided to take the database offline.
thanks
Filip Kata
Just take into account that if you don't have free spaced exactly after
your LUN you have to wait till all LUNs placed after one you are
resizing will be reorganized in order to have storage array extending
LUN's size. So if your LUN is last in raid group it will be done
immediately, if in different place you will have to wait. Sometimes it
can take a lot of time, depending on size of the LUNs and other factors.
--
Pozdrawiam
Filip Kata
W.B.
Hindsight being 20/20 in the future to avoid disruption you are better off
presenting a NEW lun to the AIX system that you can then just extendvg,
rather than extending the LUN from the SAN.
ienet
Yes, we've been through resizing the LUN from the SAN management
console, it took about 2 hours.
You're right, it should have been better to present a new LUN and
extend the vg, it will certainly be done the next time.
scott
>
> - Show quoted text -
Hi
Off the top of my head I cant remember what SAN storage we use,
however I do know that with the latest drivers and AIX TL's that we
dont seem to have to varyoff/on the VG when doing a chvg -g. We
havent had to do that since we were on older drivers and/or TL levels.
If the chvg -g does need a varyoff/on then it will say so when you run
it, so AFAIK its safe to run it and see what happens, if it works then
thats good, if not then varyoff/on so you *may* need to be prepared to
schedule downtime at a later date should it not work.
If the chvg -g works then no downtime is needed at all to extend the
filesystem even if you do need to increase the number of LP's of the
LV as this can all be done on the fly.
My preferance would be to always extend an exisiting LUN rather than
add a new one as the more disks you have the harder the management
gets.
Regards,
Scott
F. Michael Orr
The fact that this is on a SAN is irrelevant. As the first respondent
answered, the first step would be the 'chvg -g' command in order to have
the volume group see and create additional PP's. Assuming that works,
you would still have to extend the filesystem itself, though. The
simplest way for you to do that, given the fact that it is a JFS2
filesystem, is to run 'smitty chjfs2', select '/siebel', and add 1 byte
to the filesytem; the underlying command will round that up to the next
even LP size. Continue to run 'smitty chjfs2' against the filesystem,
adding 1 byte each time, until you run out space. If you don't know how
to calculate the space allocation in order to do it all at once, this
will work, though it will be tedious.
And a purely opinion statement. I believe it is better to add LUNs to a
VG than it is to increase an existing one, contrary to the original
respondent. The process of creating LUNs and making them visible to an
AIX system is pretty straightforward and not usually prone to error. If
a SAN has multiple disk groups, this also allows one to allocate the
additional LUNs in multiple disk groups, thus spreading the I/O load over
more heads than is reasonable for a single RAID5. However, either will
work.