let me restructure your questions a bit:

It is perfectly OK and in fact the command was made for exactly this purpose. Still, i think you do not need it, see below.

This - the splitting you intend - makes sense only in a specific kind of situation, so please describe your hdisk-devices a bit better. What are they (single SCSI-disks, RAID-sets, LUNs from SAN, ...) and how do you access them?

First a little theory, so that ou can understand the output better:
Here you see several of the "layers" i talked about in a previous post at work: The LV consists of LPs (leftmost column) numbered 0001, 0002, 0003, ... and the space in this LV is continuous. That means that when byte nr. X is the last byte in in LP 0001 then byte nr X+1 is the first byte in LP 0002. Now, the LP 0001 consists in fact of two PPs, which hold identical copies; PP0175 on hdisk1 and PP 0111 on hdisk2. Similarily for all the other LPs.

The first question is if you really need the LV-copies. writing in parallel is a tad slower than writing on a single LV (without copies) and it might help with the performance if you do away with the mirroring. You will have to decide if the loss of security outweighs the gain on performance or if it is the other way round.

Second, you can place the LPs also in this way (schematically):

Code:

LP    PP1  PV1
0001  0001 hdisk1
0002  0001 hdisk2
0003  0001 hdisk3
0004  0001 hdisk4
0005  0002 hdisk1
0006  0002 hdisk2
0007  0002 hdisk3
0008  0002 hdisk4
[...]

The LVM of AIX has a special provision for doing that, called (somewhat counterintuitively) "Inter-Policy", look here:

Code:

# lslv -l mylv
mylv:/some/where
PV                COPIES        IN BAND       DISTRIBUTION  
hdiskpower2       1670:000:000  24%           270:410:409:409:172 
# lslv -L ap33p1lv
LOGICAL VOLUME:     mylv                   VOLUME GROUP:   myvg
LV IDENTIFIER:      00534b7a00004c000000011cd5e0067e.1 PERMISSION:     read/write
VG STATE:           active/complete        LV STATE:       opened/syncd
TYPE:               jfs2                   WRITE VERIFY:   off
MAX LPs:            4096                   PP SIZE:        512 megabyte(s)
COPIES:             1                      SCHED POLICY:   parallel
LPs:                1670                   PPs:            1670
STALE PPs:          0                      BB POLICY:      relocatable
INTER-POLICY:       minimum                RELOCATABLE:    yes
INTRA-POLICY:       middle                 UPPER BOUND:    32
MOUNT POINT:        /some/where            LABEL:          /some/where
MIRROR WRITE CONSISTENCY: on/ACTIVE                              
EACH LP COPY ON A SEPARATE PV ?: yes                                    
Serialize IO ?:     NO                                     
INFINITE RETRY:     no

At "minimum" the LVM places the LPs on the PPs in a way so that the minimum possible hdisks are involved. At "maximum" it will try to spread it over as many hdisks as possible, thus arriving at a placement similar to what i have sketched out above.

Note, btw, that the smaller the PP size you use (this is a property of the VG so you might have to create it anew and start over from scratch) the better it is for the effect to take place. You are ultimately trying to use the internal cache of the hdisks for maximum effect and the PPs should be small enough to fit into this cache. 512MB, like in my example, would be too big for that.

If you really have to create the VG anew it might also be a good idea to create a RAID set (faster than single disks but slower than a stripe set) or even a stripe set (faster than the RAID but lacking the security of the RAID). See this little tutorial for details about RAIDs, striping, etc..

You can even more fine-tune the creation process of the LV by using a so-called "map file" and using the "-m" switch (see the man page of "mklv" for details). Basically you can explicitly state which PP(s) should represent any given LP of the LV that way.

Further, please tell us which kind of data the FS holds. You already said "mostly writing log files", but a little more detail would help: many small files, a few very large files, do the files change often or are they mostly appended? How often are files deleted and recreated (like in log rotation)? How many processes write (typically) concurrently to the FS. It might be that you can gain a lot with different OS tuning parameters without even having to change the disk layout.

At last, about "migratepv": if you really need it (which is, as shown above, not sure IMHO) you will want to remove any mirror copy from the LV prior to migrating its PPs around. It is simply only half the work because every PP has to moved separately. Unmirror the LV you want to migrate, do the migration and when that is done create a new mirror. You can use a map file (see above, the "-m" switch) for this too.

I hope this helps.

bakunin