AIX

Hi Everybody,

Is it possible to extend a Filesystem by adding a new LV that exist on different VG to this Filesystem?


Thanks in advance.

I suggest having a play with "smit", it's normally pretty good at being up front with what your options are, if it gives it as an option, it is legal to do it. If the command fails, it should tell you why.

@porter: c'mon! This is not an answer, this is a zero-message. He asks if it is possible and you tell him to use SMIT?? SMIT is a frontend, nothing more, if it is possible, it is possible regardless of using SMIT or not and if it isn't it will be impossible, again reagardless of using SMIT or not.

This is not the first time i see you giving such non-answers. Are you posthunting?

@Threadstarter: no, that is not possible. LVs (Logical Volumes) belong to a certain VG (Volume Group). A VG is a logical construct which combines several PVs (Physical Volumes: pyhsical disks, RAID volumes, SAN-shares, etc.) to one manageable entity. The disks are split into (more or less anonymized) parts (the "Physical Partition", PP) and given to a pool which can be assigned to the LVs in the VG. Most of the times LVs contain (exactly one) FS, but LVs could also host a swapspace, a boot partition, and some other things (you could even decide to use it as a raw device although this makes no sense any more nowadays), but save for these you could use "LV" and "FS" interchangeably - most of your logical volumes contain a filesystem.

Usually VGs are used for a group of LVs which are somehow logically connected. For instance, if you have several database instances on one machine it might be a good idea to create a VG for every instance. In every of these VGs you would have one FS (LV) for the binaries, one for the logs, one for the tablespaces, etc.

So the only reason why you would want to transfer a filesystem from one VG to another would be space considerations. In this case it is better to:

add more PPs to the LV if there are enough left in the pool (use lsvg <VGName> to check). dont forget to expand the filesystem after resizing the LV, it is not done automatically. Do the following:

get the PP size to find out how many PPs you will have to add to expand the LV for a certain size. (lsvg <VGName>) Get the name of the LV as you have perhaps only the mountpoint of the corresponding filesystem (lsvg -l <VGName>). Now calculate how much this is in 512-byte-blocks. Use chfs to expand the filesystem accordingly (chfs -a size=+<NrOfBlocks> <mountpoint>). You can do that without umounting the FS, your application using the FS won't even notice it.

For example: The PP size is 128MB and you want to add 2GB to the LV mytestlv mounted on /my/testlv. You will have to add 16 PPs. (I won't explain possible considerations about mirroring here.) Issue

extendlv mytestlv 16

Now calculate how much this is in 512-byte-blocks: 2*1024*1024*2=4194304

chfs -a size=+4194304 /my/testlv

If this is not possible because the pool of free PPs is exhausted add a new physical volume to the colume group (up to a maximum of 32)

If this is still not possible it is better to reorganize the volumegroup as a whole, using a bigger PP size (since PVs are limited to 1019 PPs the PP size determines the maximum size of the PVs used), use different storage, etc. and recreate all the LVs on the VG.

Oh, besides: you could do all that with SMIT too if you like.

bakunin

There is all kinds of new features in AIX and Supported hardware to make some things possible. With something like SVC you can extend Disks on the fly . You can then tell LVM that there is a change using chvg -g vgname (Some limitations on this does exist)

There rest I think may need to be covered as you need them in different Questions.

PORTER ???

Thanks a lot bakunin for your replay that has very useful information especially for me. Really, I appreciate replies like this, because it includes the answer (problem's solution) & the useful knowledge.
Thanks again.

I asked the above question because I faced a problem. I have a Filesystem which mounted over a specific LV. This LV belongs to a VG that consists of 2 PVs. This VG has MAX PVs = 8, and this is the main reason for my problem & I will explain why later.
Recently, the percentage of used space from this FS reached 90% & to increase this FS a new storage has been allocated to my system on SAN. This new storage consists of 9 PVs. Obviously it isn't possible to add all these PVs & this my problem.
Unfortunately, the SAN admin restricted with a policy that prevent him from giving me the required size divided into less than 7 PVs. Also I don't think it is possible to change the MAX PVs for the VG, because I didn't see this option except during the VG creation.

Finally, how can I add these PVs to increase the FS size? According to my knowledge I think the solution is to recreate the VG.
If am right & the only way is to recreate the VG what is the best scenario to do that without losing the existing data?

Thanks in advance

Hm, I get harraunged for suggesting smit, the reason I do so is because I find it very good for providing the dynamic list options in many scenarios, such as managing volumes.

@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