FAQ: Error Resizing a Logical Volume in AIX

"There’s No Such Thing As A Silly Question" -- does the cliche sound familiar? In this part of pimp-my-rig reloaded, technical questions are answered. Mail them to me and I will post the answers here. If you have a better answer, by all means share it with us.

The beauty of a volume manager is that the backing device, or meta device as what other operating systems would call it, is made independent from the operating system. The storage device itself is controlled by another layer that is put in place by the volume manager. Thereby, the operating system does not have direct control over this storage. This way the volume group and its underlying logical volumes can be resized on demand.

Several operating systems implement this kind of obscurity including but not limited to Linux and Unix. Today we take a look at this functionality in AIX. However, resizing volumes sometimes has its own set of headaches and we need to be prepared to get around the configuration and the issues encountered each time.

Q. A colleague was trying to resize a logical volume since the application has demanded increased disk space and more breathing room. However, what he thought was a simple change to execute resulted in an error. And thus opened additional learning opportunities for us both. The change and its error was below:

root@host:/root => chfs -a size=+24G /dev/appdata01lv
0516-787 extendlv: Maximum allocation for logical volume appdata01lv
        is 3804.
root@host:/root => lslv appdata01lv
LOGICAL VOLUME:     appdata01lv            VOLUME GROUP:   appvg
LV IDENTIFIER:      00c175f4004c00635401257a0b3fe3.9 PERMISSION:     read/write
VG STATE:           active/complete        LV STATE:       opened/syncd
TYPE:               jfs2                   WRITE VERIFY:   off
MAX LPs:            3804                   PP SIZE:        32 megabyte(s)
COPIES:             1                      SCHED POLICY:   parallel
LPs:                3804                   PPs:            3804
STALE PPs:          0                      BB POLICY:      relocatable
INTER-POLICY:       maximum                RELOCATABLE:    yes
INTRA-POLICY:       middle                 UPPER BOUND:    1024
MOUNT POINT:        /mount/point/info      LABEL:          /label/has/been/hidden
MIRROR WRITE CONSISTENCY: on/ACTIVE
EACH LP COPY ON A SEPARATE PV ?: yes
Serialize IO ?:     NO
DEVICESUBTYPE : DS_LVZ
COPY 1 MIRROR POOL: None
COPY 2 MIRROR POOL: None
COPY 3 MIRROR POOL: None

A. This change can be done online without losing data nor incurring any downtime. And that is the beauty of a volume manager.

As seen from the output of the commands above, he was trying to add 24GB of space to an existing volume "appdatal01lv" but the logical volume itself seems to deny the adding of additional space to it saying that the "Maximum allocation for logical volume appdata01lv" has been hit.

He got a bit stuck here for a bit, while I was reviewing my notes from changes that I executed before. I knew I had hit this roadblock before.

From a previous change I implemented, I modified the property "MAX LPs" for the target logical volume before adding space to that volume. That step, though sometimes no longer necessary, was missing in his procedure and this time it is not optional.

We implemented the additional step to his procedure and it executed with success.

root@host:/root => chlv -x 7500 appdata01lv
root@host:/root => chfs -a size=+24G /dev/appdata01lv
Filesystem size changed to 299630592
root@host:/root => lslv appdata01lv
LOGICAL VOLUME:     appdata01lv            VOLUME GROUP:   appvg
LV IDENTIFIER:      00c175f4004c00635401257a0b3fe3.9 PERMISSION:     read/write
VG STATE:           active/complete        LV STATE:       opened/syncd
TYPE:               jfs2                   WRITE VERIFY:   off
MAX LPs:            7500                   PP SIZE:        32 megabyte(s)
COPIES:             1                      SCHED POLICY:   parallel
LPs:                4572                   PPs:            4572
STALE PPs:          0                      BB POLICY:      relocatable
INTER-POLICY:       maximum                RELOCATABLE:    yes
INTRA-POLICY:       middle                 UPPER BOUND:    1024
MOUNT POINT:        /mount/point/info      LABEL:          /label/has/been/hidden
MIRROR WRITE CONSISTENCY: on/ACTIVE
EACH LP COPY ON A SEPARATE PV ?: yes
Serialize IO ?:     NO
DEVICESUBTYPE : DS_LVZ
COPY 1 MIRROR POOL: None
COPY 2 MIRROR POOL: None
COPY 3 MIRROR POOL: None

To change the "MAX LPs" property, chfs -x NEW_VALUE has to be executed to the logical volume.

For this particular error message, the solution is to modify "MAX LPs" to cater to the additional storage requirement. You can check the current allocation from the value of "LPs" just another line below "MAX LPs". The change should not make the value of LPs go over its set MAX.

If you have changes involving increase in disk space using the AIX volume manager, better check for the value of "MAX LPs" before executing the change. Or you can note the additional step above so when implementation time comes, it will proceed without further delays.

You might also be interested in:

Feedback

We at pimp-my-rig strive to keep on improving, help us reach that goal by leaving comments or constructive criticisms. Don't miss out on our next feature -- subscribe via RSS (What is RSS?).

Share This

0 comments: