AIX

Hi,
Below is the layout of one of my AIX 5100-03's rootvg look like. Some of my lvs are grown over to multiple hdisks (bolded lines). can somebody explain me why is that happening and how to stop that or get those spanned data into a single hdisk.
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 39 39 1 open/syncd N/A
hd8 jfslog 1 1 1 open/syncd N/A
hd4 jfs 16 16 2 open/syncd /
hd2 jfs 183 183 2 open/syncd /usr
hd9var jfs 16 16 1 open/syncd /var
hd3 jfs 19 19 1 open/syncd /tmp
hd1 jfs 14 14 2 open/syncd /home
hd10opt jfs 489 489 2 open/syncd /opt
paging00 paging 25 25 1 open/syncd N/A

lsvg -p rootvg
rootvg:
PV_NAME PV STATE TOTAL PPs FREE PPs FREE DISTRIBUTION
hdisk0 active 537 49 00..49..00..00..00
hdisk1 active 537 114 00..00..00..06..108
hdisk4 active 537 375 108..52..00..107..108

lsvg rootvg
VOLUME GROUP: rootvg VG IDENTIFIER: 0020392500004c00000000f3591c20a6
VG STATE: active PP SIZE: 8 megabyte(s)
VG PERMISSION: read/write TOTAL PPs: 1611 (12888 megabytes)
MAX LVs: 256 FREE PPs: 538 (4304 megabytes)
LVs: 12 USED PPs: 1073 (8584 megabytes)
OPEN LVs: 11 QUORUM: 2
TOTAL PVs: 3 VG DESCRIPTORS: 3
STALE PVs: 0 STALE PPs: 0
ACTIVE PVs: 3 AUTO ON: yes
MAX PPs per PV: 1016 MAX PVs: 32
LTG size: 128 kilobyte(s) AUTO SYNC: no
HOT SPARE: no

...and .....

<root@silo.dsm.pwj.com/> lslv hd1
LOGICAL VOLUME: hd1 VOLUME GROUP: rootvg
LV IDENTIFIER: 0020392500004c00000000f3591c20a6.8 PERMISSION: read/write
VG STATE: active/complete LV STATE: opened/syncd
TYPE: jfs WRITE VERIFY: off
MAX LPs: 512 PP SIZE: 8 megabyte(s)
COPIES: 1 SCHED POLICY: parallel
LPs: 14 PPs: 14
STALE PPs: 0 BB POLICY: relocatable
INTER-POLICY: minimum RELOCATABLE: yes
INTRA-POLICY: center UPPER BOUND: 32
MOUNT POINT: /home LABEL: /home
MIRROR WRITE CONSISTENCY: on/ACTIVE
EACH LP COPY ON A SEPARATE PV ?: yes

thanks in advance..

is there something to do with INTER-POLICY?

This happens, because when the VG and LVs were created, there was no restriction on which PVs they will go - ie. none selected it from smit or mkvg or mklv.
If none was selected, they take whatever hdisk has free space and is member of that VG.

Since there is no mirror (as you can see by the number of PPs which is the same amount for LPs) even parameters like
are not taken into account, since you have
for each LV.

If you are using an internal raid controller or external raid disks for rootvg, all might be good. If not, I recommend strongly that you get a 4th or 5th and 6th disk (if the space is sufficient then) and start (AIX) mirroring all the LVs (lvcopy).
Else if you have a crash, you have to rely solely on your mksysb, after replacing defect disk(s).
After everything is mirrored, you will have to use "migratelp" to move each copy of an LP (PP) to another hdisk, so that the mirror makes sense in the end.

Your assumption is correct. "Inter-policy" means: either keep the LV at as few PVs as possible or distribute it over as many PVs as possible. The latter option was of much higher significance in the days when "PV" was a physical disk, not a share on some SAN-subsystem like today. Distributing the LV over many physical disks was a way to maximize disk-troughput back then (keep in mind that the LP size was much smaller back then and likely to fit in the disks cache).

Regarding your initial question: Your rootvg has been expanded and probably the LVs have not always been what they are now but were increased in size several times. The system simply had no other choice than to assign parts of different disks to fulfill the requirements.

You can correct this by running a "reorgvg" (see the man page for details, its straightforward), but i suggest doing a backup before first (to be real sure check the backup by installing it to a different machine) and second doing it during a time when the systems consumption is as low as possible - preferably at some maintenance downtime.

As i can see your rootvg is not mirrored. Is there a reason for this? If not: i would suggest making correcting this your first priority. This is very likely your biggest hazard here, in comparison the LV issues are negligeable.

bakunin

thanks guys for the info..