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: