@porter: Using SMIT is not wrong - it is just no answer to the problem at hand. If you ask me, where the next store is and I tell you to "drive there on the right side", this would be not wrong too (here you *have* to drive on the right side of the street) - but it wouldn't be very useful for you in finding a store either.

To aldowsarys problem:

I told you about "PP size" and that a PP is the smallest amount you can assign to LVs. So it would be a clever idea to use the smallest PP size possible, right? WRONG!! There is a limitation in LVM:

A single PV can hold only 1019 PPs

That means, that (roughly) the size you select for PPs in MBs is the maximum size of the PVs in this VG in GB.

There existed many VGs out there which were poorly designed and had too small PP sizes. Because of this new disks added to these VGs had to be pretty small and the VGs couldn't keep up with the necessities. The best way to deal with this would have been to back these VG up and create them anew with sensible values. Instead of this IBM came up with a clever hack: by (mis-)using some bits in the bookkeeping area of the VG (the correct name is: VGDA) they introduced the "factor".

I told you VGs can hold up to a maximum of 32 disks (PVs). The factor now let you have the double (or quadruple) number of PPs in a single disk, but at the expenditure of of limiting the number of disks in a VG. With a factor of 2 you can have 2038 PPs on a single disk, but only 16 disks in the VG, in your case there seems to be a factor of 4 in effect. This is why you can have only 8 disks (PVs) in your VG.

The best advice i can give you is: back up, create anew, then restore your backup. Everything els is just dragging along an already cumbersome misdesign, which will not get better over time, but perhaps grow into an even bigger obstacle than it already is.

Plan this change (which is a MAJOR change!) thoroughly!

Identify all the LVs in your VG and write down how they are created, where they are mounted, etc.:

lsvg -l <VGNamename>

If you can get your SAN admin to give you more space temporarily go for it! Create the new VG (rename the old VG first to give the new one the same name as the old) alongside the old one so you can always have a look at the original.

Create a backup of all the LVs in the old VG.

Plan carefully: which amount of space are the LVs/FSs in the VG going to need in the foreseeable future? That determines (see above) which PP size is sensible, because this limits the size of disks you can add later. Leave room for extension! (I mean that in EVERY respect - nowhere go to any limit.)

Only when you have made up (really made up!) your mind start implemening your plan: create a backup, create the new VG, create the LVs (give them sensible names, it makes life easier later), create filesystems. You can backup the file /etc/filesystems before you start and use the entries there as a blueprint for your new filesystems.

One more thing: if you have old VGs they are probably created with the JFS filesystem type. If you recreate them use JFS2 instead, as this is more robust and a little bit faster than the older JFS.

bakunin