1016 Physical Partitions Per Disk in a Volume Group:

     In the design of LVM, each Logical Partition
maps to one Physical Partition.  And, each Physical
Partition maps to a number of disk sectors.  The design
of LVM limits the number of Physical Partitions that LVM
can track PER DISK in a volume group to 1016.  In most cases,
not all the possible 1016 tracking partitions are used by a disk.
The default size of each Physical Partition during a
"mkvg" command is 4 MB, which implies that individual
disks up to 4 GB can be included into a volume group.

     If a disk larger than 4 GB is added to a volume
group (based on usage of the default 4 MB size for
Physical Partition) the disk addition will fail with a
warning message that the Physical Partition size needs
to be increased.*  There are two instances where this
limitation will be enforced.  The first case is when the
user tries to use "mkvg" to create a volume group where
the number of physical partitions on one of the disks in
the volume group would exceed 1016.  In this case, the
user must pick from the available Physical Partition ranges of:

1, 2, (4), 8, 16, 32, 64, 128, 256

Megabytes and use the "-s" option to "mkvg".  The second
case is where the disk which violates the 1016 limitation
is attempting to join a pre-existing volume group with
the "extendvg" command.  The user can either recreate the
volume group with a larger Physical Partition size (which
will allow the new disk to work with the 1016 limitation)
or the user can create a standalone volume group (consisting
of a larger Physical Partition size) for the new disk.

     In AIX 4.1 and 3.2.5, if the install code detects
that the rootvg drive is larger than 4 GB, it will change
the "mkvg -s" value until the entire disk capacity can be
mapped to the available 1016 tracks.**  This install change
also implies that all other disks added to rootvg, regardless
of size, will also be defined at that new Physical Partitions size.

For RAID systems, the /dev/hdiskX name used by LVM in AIX may
really consist of many non-4GB disks.  In this case, the 1016
limitation still exists.  LVM is unaware of the size of the
individual disks that may really make up /dev/hdiskX.  LVM bases
the 1016 limitation on the AIX recognized size of /dev/hdiskX,
and not the real independent physical disks that make up /dev/hdiskX.

The questions asked of this issue are:
1) What are the symptoms of this problem?
2) How safe is my data?  What if I never use mirroring or migratepv?
3) Can I move this volume group between RS/6000 systems and versions
   of AIX?

Here are the answers:
A) What are the symptoms of this problem?
     The 1016 VGSA is used to track the "staleness of mirrors".
     If you are in violation of 1016, you may possibly get a false
     report of a non-mirrored logical volume being "stale" (which
     is an oxymoron) or you may get a false indication that one of
     the your mirror copies has gone stale.  Next, migratepv may
     fail because migratepv briefly uses mirroring to move a logical
     volume from one disk to another.  If the target logical
     partition is incorrectly considered "stale", then the migratepv
     cannot remove the source logical partition and the migratepv
     command will fail in the middle of migration.

B) How safe is my data?  What if I never use mirroring or migratepv?
     The data is as safe (in your mind) as the day before you found
     out about 1016 violations.  The only case where data may be
     lost is if one is mirroring a logical volume and ALL copies go
     bad at the same time and LVM isn't aware of it because the
     copies that go bad are beyond the 1016 tracking range.  However,
     in this case, you would lose data even if you were within the
     1016 range.  If you never mirror or use migratepv, then this
     issue shouldn't concern you.  But, it might be unwise to state
     you'll NEVER use either of those options.

C) Can I move this volume group between RS/6000 systems and versions
   of AIX?
     Yes you can.  The enforcement of this 1016 limit is only
     during mkvg and extendvg.  The "safeness" of the data on the
     volume group on AIX 3.2 is the same as it is on AIX 4.1.


* This bug was fixed in apar ix48926.  Current AIX 3.2.5 and
4.1.1, which do not have this fix on applied, will allow the
creation of volume groups with more than 1016 partitions.  The
implication of this bug allowing more than 1016 physical
partitions is that the user may access all portions of the logical
volume.  However during disk mirroring, the status of partitions
beyond the 1016 limit will not be tracked correctly.  If mirrors
beyond the 1016 range become "stale", LVM will not be aware of
their condition and data consistency may become an issue for
those partitions.  Additionally, the "migratepv" command creates
mirrors and deletes them as a method for moving logical volumes
around within/between disks.  If the 1016 limit is violated,
then the "migratepv" command may not behave correctly.
The user should pick up apar ix51754, which clarifies the error
message when this condition is detected.  Additionally, the user
can read the non-ptf documentation apar ix50874 which is a companion
to ix48926 and ix51754.

** This bug was fixed for AIX 3.2.5 rootvg install in apars
ix46862 and ix46863.  This bug does not exist in AIX 4.1.1.