I was performing a volume group re-org i.e. changing the INTER-POLICY of a logical volume from minimum to maximum.

 

# lslv fixeslv| grep INTER

INTER-POLICY:       minimum                RELOCATABLE:    yes

 

# chlv -e x fixeslv

 

# lslv fixeslv| grep INTER

INTER-POLICY:       maximum                RELOCATABLE:    yes

 

I attempted to run the reorgvg command. I was greeted by the following error message!

 

# reorgvg tempvg fixeslv

0516-966 reorgvg: Unable to create internal map.

 

I ran the command again, this time with truss. I found that the /usr/sbin/allocp command was being called and was failing. I determined this must be because of a lack of space at the logical volume layer.

 

# /usr/sbin/allocp -?

/usr/sbin/allocp: Not a recognized flag: ?

0516-422 allocp: [-i LVid] [-t Type] [-c Copies] [-s Size]

        [-k] [-u UpperBound>] [-e InterPolicy] [-a InterPolicy

 

The truss output showed:

 

statx("/usr/sbin/allocp", 0x2FF21ED8, 76, 0)    = 0

statx("/usr/sbin/allocp", 0x20009E70, 176, 020) = 0

kioctl(2, 22528, 0x00000000, 0x00000000)        Err#25 ENOTTY

kfork()                                         = 3735812

_sigaction(20, 0x00000000, 0x2FF21F20)          = 0

_sigaction(20, 0x2FF21F20, 0x2FF21F30)          = 0

kwaitpid(0x2FF21F90, -1, 6, 0x00000000, 0x00000000) = 3735812

 

And yes, my volume group was indeed out of free PPs!

 

# lsvg tempvg

VOLUME GROUP:       tempvg                   VG IDENTIFIER:  00f6027300004c0000000130773bdb73

VG STATE:           active                   PP SIZE:        512 megabyte(s)

VG PERMISSION:      read/write               TOTAL PPs:      99 (50688 megabytes)

MAX LVs:            256                      FREE PPs:       0 (0 megabytes)

LVs:                1                        USED PPs:       99 (50688 megabytes)

OPEN LVs:           1                        QUORUM:         2 (Enabled)

TOTAL PVs:          2                        VG DESCRIPTORS: 3

STALE PVs:          0                        STALE PPs:      0

ACTIVE PVs:         1                        AUTO ON:        yes

MAX PPs per VG:     32768                    MAX PVs:        1024

LTG size (Dynamic): 256 kilobyte(s)          AUTO SYNC:      no

HOT SPARE:          no                       BB POLICY:      relocatable

PV RESTRICTION:     none

cgaix7[/opt] >

 

Silly me, it clearly states in the reorgvg man page that there must be at least one free PP in the volume group for the command to run successfully.

 

2    At least one free physical partition (PP) must exist on the specified volume group for the reorgvg command to run successfully. For mirrored logical volumes, one free PP per physical volume (PV) is required in order for the reorgvg command to maintain logical volume strictness during execution; otherwise the reorgvg command still runs, but moves both copies of a logical partition to the same disk during its execution.

 

So I shrunk the file system in question (there was a large amount of allocated but unused file system space, so it was safe to shrink it).

 

# chfs -a size=-40G /fixes

Filesystem size changed to 19922944

Inlinelog size changed to 38 MB.

 

Now I had plenty of free PPs in my volume group.

 

# lsvg tempvg

VOLUME GROUP:       tempvg                   VG IDENTIFIER:  00f6027300004c0000000130773bdb73

VG STATE:           active                   PP SIZE:        512 megabyte(s)

VG PERMISSION:      read/write               TOTAL PPs:      99 (50688 megabytes)

MAX LVs:            256                      FREE PPs:       80 (40960 megabytes)

LVs:                1                        USED PPs:       19 (9728 megabytes)

OPEN LVs:           1                        QUORUM:         2 (Enabled)

TOTAL PVs:          1                        VG DESCRIPTORS: 2

STALE PVs:          0                        STALE PPs:      0

ACTIVE PVs:         1                        AUTO ON:        yes

MAX PPs per VG:     32768                    MAX PVs:        1024

LTG size (Dynamic): 256 kilobyte(s)          AUTO SYNC:      no

HOT SPARE:          no                       BB POLICY:      relocatable

PV RESTRICTION:     none

 

And reorgvg now ran with success.

 

# reorgvg tempvg fixeslv

0516-962 reorgvg: Logical volume fixeslv migrated.

 

I found some interesting information in the lvmcfg alog file.

 

# alog -o -t lvmcfg | grep reorgvg

[S 2359470 3080260 06/15/11-19:26:36:915 reorgvg.sh 580] reorgvg tempvg fixeslv

[E 2359470 0:964 reorgvg.sh 23] reorgvg: exited with rc=1

[S 3145780 3080260 06/15/11-19:28:19:645 reorgvg.sh 580] reorgvg tempvg fixeslv

[E 3145780 190:611 reorgvg.sh 23] reorgvg: exited with rc=0

 

I can see when my reorgvg failed (rc=1) and when it succeded (rc=0). This is also a good way of determining when a reorgvg command is issued and when it finished. Of course, an easier way would be to start the reorgvg command with the time command. It will produce a nice little summary of the time taken.

 

# time reorgvg tempvg fixeslv

0516-962 reorgvg: Logical volume fixeslv migrated.

 

real    3m12.94s

user    0m1.52s

sys     0m4.60s

 

But if I forgot to use the time command, I can look at the lvmcfg alog file for an answer. In the following example, the reorgvg.sh process is started at 23:49. The entry in the log file begins with an uppercase S. The entry that starts with an uppercase E indicates the end of the reorgvg.sh process.  It is the information in the third field that tells me how long the process ran for in seconds:milliseconds.

 

# alog -o -t lvmcfg | grep reorgvg | tail -3

[S 3735990 3080260 06/15/11-23:49:58:491 reorgvg.sh 580] reorgvg tempvg fixeslv

[E 3735990 192:969 reorgvg.sh 23] reorgvg: exited with rc=0

 

In this case, my “reorgvg” took 192 seconds, 969 milliseconds (192:969), which equates to a little over 3 mins and matches the time reported from the time command (above).

Here is the format of an end (E) entry in the lvmcfg logs:

[E 237694 1:733 mklv.sh 71] mklv: exited with rc=0

·         E = Verbosity

·         237694 = pid

·         1:733 = time elapsed since start entry(s:ms)

·         mklv.sh = file writing to log

·         71 = line number where log is being written

·         mklv: = command exiting

·         exited with rc=0 = exit code of command

 

More information on the new LVM logging techniques can be found at the following link:

 

http://www.aixmind.com/?p=809