AIX

Basically yes. The long answer is that you seem not to have a firm grasp of LVM concepts and terminology. See below.

Lets first deal with your other problem (with the big FS). Notice the difference in your provided output, i have snipped the important part:

Code:

MAX LVs:            256                      FREE PPs:       13104 (1677312 megabytes)
LVs:                0                        USED PPs:       0 (0 megabytes)

Code:

# /usr/sbin/mklv -y'lv_usr1' -t'jfs2' -c'2' -L'usr1' -x'32512' vg_usr1 6552
0516-032 lcreatelv: Illegal physical partition number.
0516-822 mklv: Unable to create logical volume.

Code:

MAX LVs:            256                      FREE PPs:       1103 (141184 megabytes)
LVs:                2                        USED PPs:       12001 (1536128 megabytes)

Notice that you have 2(!) and not one LVs after creating the first LV and you have 1103 PPs free after using 12000 out of the initial 13104. You have one LV more than expected and one PP less than expected, right?

The reason for this is that JFS is a JOURNALED filesystem and as such it needs a journal. Issue a

Code:

lsvg -l <vgname>

and you will see an (automatically created) LV of type "jfslog" with the size of 1 PP. This has been created automatically when you issued your "mklv" command to create a LV without an "inline" log. JFS2 can use either an external jfslog device (one per VG) or an inline log (one per LV). This is why your "mklv" command failed: the jfslog LV was created first and then you missed one PP to fulfill your size demands.

Here is a short introduction to LVM concepts. I suggest you download and study some of IBMs Redbooks to that.

We start with disks. What a "disk" is can be a wide variety of devices: physical disks, RAID sets, LUNs, etc., basically everything that has a "hdisk"-device entry in "lsdev". We will consider a disk to be a real, physical disk at first. (Let us start simple and go from there.)

The first thing we have to create is a "volume group". VGs are purely logical constructs, containers. You create a VG and give it at least one disk. A disk inside a VG is called "physical volume", PV. Classical VGs can hold up to 32 PVs (there are "scalable" and "big" VGss, but about that later). There are commands ("extendvg", "reducevg") to add disks to a VG or remove them from one.

When a disk is added to a VG it is sliced into "physical partitions". A PP is the smallest amount of disk space a VG can deal with. Classical VGs can have a maximum of 1019 PPs in one PV, therefore a classical VG is limited to 32 x 1019 PPs in size. The PP size is therefore a vital decision and one should better err to the big side than to the small side. Bigger PPs mean you might waste some space because you cannot add less than a single PP to a FS. Selecting the PP size too small means you cannot use larger disks. Unfortunately the PP size cannot be changed, you will have to wipe the whole VG and create it anew.

Once you have a VG you can create volumes, LVs: volumes are similar to "partitions" in PCs. Raw disk space,which can be used either for filesystems or other purposes (raw devices, swap space, ...). LVs are created from (in principle) anonymized PPs. When you add a disk to a VG it is sliced up into PP-sized chunks (PPs) and these chunks are put into a big bag. Then you create a LV and give it a certain amount of PPs. You do not need to know where they come from (which PV and position) although you can control this process to the utmost extent (by using map files). You can, but do not have to (and one usually doesn't).

Notice that inside the LV there are "logical partitions", LPs. These are the logical equivalent of PPs, but abstracted. If you use a LV with one copy (unmirrored) then each PP corresponds to one LP and vice versa. When you have 2 copies there are two PPs corresponding to one LP, 3 copies would mean 3 PPs corresponding to 1 LP. The VG has an attribute controlling the allocation of these PPs: "each copy on a separate PV". This means that every PP resenting the same LP should be located on a different PV (disk). Switch the attribute off and all copies might land on the same disk.

Finally you can put filesystems (and some other things) onto a LV or use it as a raw device. The latter is often preferred by database guys (for no good reason any more, because the performance gain is next to nil nowadays). You can also put a JFS or JFS2 (and some other filesystems) ont it, you can create a paging device or system dump device. Creating a FS means you format the LV and put some FS information onto it. You can create a FS directly, in which case the underlying LV is automatically created for you (this is what you tried above and what failed). You can also grow and shrink the FS (command chfs), which will also automatically enlarge/shrink the underlying LV acccordingly. Notice that stiil the PP size is set. You can add 1 byte to the FS, but it would result in adding a whole LP (and therefore, depending on the LV copies, 1, 2 or 3 PPs) to the LV and subsequently to the FS. You can try it:

Code:

chfs -a size=+1 /some/FS

will grow "/some/FS" by not 1 byte but by the PP size.

I hope this helps.

bakunin