vg255

[Soren Morton]

We want to use vg255 for the cluster lock volume group for ServiceGuard. Anyone know the impact performace wise (If any) to changing maxvgs to 255? I don't have a test server to try this out on right now.

[James R. Ferguson]

Hi:

The LVM table size is a factor of the maximum number of logical volumes the volume group can contain (max_lv), the maximum number of physical volumes the volume group can contain (max_pv) and the size of the size of the physical extent (pe_size). The table must fit in one disk extent. This constrains some combinations of parameters.

There is nothing, however, that dictates that logical volume #255 *is* the 256th logical volume. It does not have to be named "lvol255". The name is just that, a name without penality. Further there is no requirement that the minor number of this logical volume equal decimal 255 (0xff). The only requirement is that a minor number be unique within a volume group.

Given the above, if you wish to use "lvol255" you do not need to unnecessary inflate the size of the LVM tables to match. There is no performance penailty doing or not doing this to my knowledge.

Regards!

...JRF...

[Manju Kampli]

saron,

setting maxvgs to 255 does not impact the system performance but however it will eat soem memory for reserving the table space for those number of VGs .. this space should be very minimum and can be neglected.
Regrads,
Manju

[Manju Kampli]

Soren,

A Set of data strucutre is created in the kernel for each Logical volume group on the system. Setting this parameter to high value will conserve kernel storage space by creating high number of data structure in the kernel and will increase the kernel size. I am not sure by how much the kernel size will be increased.

Hope this helps,
manju

[Carlos Fernandez Riera]

Cluster lock vg can/must be shared with data.

If you are thinking to isolate vg cluster lock you will left without use a lot of space ( 2 disks).

I can see your need of isolate vgcluster lock.

[Wodisch]

Hello Soren,

even if JRF consistently writes "lvol255" he is right about
it: there is not neccessarily a connection between the
name of a volumge group and its internal number, as
shown by "ls -l /dev/*/group"...

BUT if you really want to set the kernel parameter
"maxvgs" to 256 (it must be one greater than the
highest number used), this will have a huge impact on
your kernel's footprint in RAM, and perhaps even on
disk: the kernel has to keep copies of whatever is in
your "/etc/lvmtab" and to have space for 256 VGs *
(255 LVs * max_LE LEs + max_PV * max_PEs) is a
really huge amount of space wasted!

Do you really intend to have something like 255 VGs
each with a couple of LVs, and then "mount" these?
Every "bdf" or "mount" you enter will scroll by for ages...

Nah, I do not believe you will do that.

Name your last VG what you want, but only increase
your "maxvgs" to a little bit more than the amount of VGs
you will actually use.

Just my $0.02,
Wodisch

[Dave Wherry]

While I agree with all the replies that you should not have to increase maxvgs, I have had this happen to me. maxvgs was set to 10. I had vg00, vg01 and vg02 on the system. When I tried to create vg11 it failed with an error message something to the effect that not enough volume groups were defined. My HP ASE was here with me so I wasn't just hallucinating it.
We increased maxvgs, rebuilt the kernel and of course rebooted. Creating vg11 worked fine after that.
It could have been a fluke and the reboot after the kernel build may be what really fixed the problem. Just take it as a heads up.

Dave

[Soren Morton]

Unfortunately you can not use vg255 unless maxvgs is set to 256. The last post was correct in stating that you must change the kernel paramater to match your last vg. I tested this out before I posted this question.

I understand that the amount of required memory for the kernel will be increased, etc. etc., but has anyone actually used this many volume groups? I am looking for answeres based on experience with this type of configuration. Is there any down-side, if so what?

[Sanjay_6]

Hi people,

correct me if i'm wrong. But from dale message it seems that if you naming the Vg as vg11 and the maxvgs parameter in the kernel is set for 10, but at that time onlt three other VG's exist, he cannot create a VG with the name VG11. I can understand if he faces problem with the minor no of the group file, but can'e the name be vg11 with a group file with minor no. below 10 ?.

Hi soren, do you want to name your lock Vg as vg255 or you want the VG group file minor no as 255. If it is the first, i think you should be able to do that without incrasing the maxvgs parameter in the kernel. If it is the second then you can increase the maxvgs parameter in the kernel to 256 and i don't think it should increase your overhead.

That is my opinion.

Hope this helps.

thanks

[Rita C Workman]

Hi Dave,

The reason you got that error when you went to create volume group 11, was not because of maxvgs being set to 10...but this:
0x110000 .. 11 is in hex, and when the system translates this to the dec value you get 17. It is this value (17) that conflicts with the (10) value set in maxvgs. So when you increased your maxvgs value you must have set it higher than 17..so then you worked. I believe this is what they are referring to.

Hope this helps a little,
Rita

[Soren Morton]

Yes I could make vg255 with a minor # of 20(0x14000) or something other than ff. However, thinking long-term we will use volume group 20 and if someone re-uses this minor # ....?

There are too many issues with using a non-matching minor #.

So, does anyone out there have maxvgs > 200? It does not sound like it, so I will have to put together a environment to test on. So much for the easy way.