Originally posted by: SystemAdmin

I've read over the features for big and scalable VGs, and see the advantages of them. But are there any disadvantages of using scalable VGs?

If you have a volume group that is unlikely to need the features of scalable VGs, is there any disadvantage of using them anyway?

Originally posted by: SystemAdmin

Lots of page views... but no responses.

Here is what I've found out so far:

• You can create a volume group as a regular VG and convert it to a big or scalable VG later. converting to a "big" vg can be done with the file volume group and it's file systems online. You will need to have some space available in order for some of the control structures to be expanded. Converting to a scalable VG requires the VG to be varied off during the conversion.

• because the control structures for LVM are larger in big or scalable VGs, LVM operations can take "considerably longer" to quote the "chvg" man page. Regular IO access does not appear to be affected, only LVM operations, such as extendvg, mklv, lsvg etc. This can be important for HACMP systems.

You can see the man page for chvg for more details about the conversion process.

It appears that it isn't a good reason to create a volume group as a big or scalable vg if the larger size and number of PVs is not needed. When in doubt, it seems safe to create it as a regular VG up front. It looks like it is generally an easy process to convert the file system later.

If you can accomplish your large file system goals by upsizing the PP size or using the "chvg -t" scaling factor, you might be better off doing that rather than converting the file system.