Long time ago, when I studied the Veritas LVM, I knew the PVG term which meant physical volume group and the physical volumes in the same PVG were from the same SAN or same disk. Usually there is a single point of failure of the same PVG and when we build mirror or other soft arrays, we have to distribute the segment on different PVGs not different PVs.
I tried to find the similar concept on AIX many times and failed always until last day I got a similar concept named mirror pool here.
Last day I had to add four LUNs from two SAN devices to a VG and extent the current jfs2 filesystem. There were already more than ten PVs in the VG so I had to make sure the LP mirrors of every LV were located on different SAN devices. More important, when the customer extent such filesystems by themselves, such rule should be followed automatically.
So to archive the goal, I had to assign all the current PVs to different mirror pools then change all the LVs to user different mirror pools for different copies with below commands:
- chpv -p PoolA hdisk2
- chpv -p PoolA hdisk3
- chpv -p PoolA hdisk4
- chpv -p PoolA hdisk5
- chpv -p PoolB hdisk12
- chpv -p PoolB hdisk13
- chpv -p PoolB hdisk14
- chpv -p PoolB hdisk15
- extendvg -p PoolA sapdata hdisk6 hdisk7
- extendvg -p PoolB sapdata hdisk16 hdisk17
- chlv -m copy1=PoolA -m copy2=PoolB fsdata1
- chlv -m copy1=PoolA -m copy2=PoolB fsdata2
Then I extended the filesystem fsdata1 and fsdata2 and verified all the new PPs were on different mirror pools.
Note: I run the 'reorgvg sapdata fsdata1' to correct the previous existing wrong allocation of PPs while it lasted several hours and finally I had to cancel it manually. The size of fsdata1 is about 1.6T.
The above experience let me know the weakness of mirror pool. When I run reorgvg the fix allocation issue of LV, it will make sure the first PP is from PoolA and the second one is from PoolB, while in fact I just want to make sure both PPS are from different mirror pools.
