Volume group parameters

[Steven Hargus]

I want to move a large amount of data from disks in existing volume groups to bigger disks on a newer EMC frame. Since the disks are bigger than max_pe_per_pv on the volume groups, I will have to create new volume groups and copy the data. The question is, what parameters should I use to create these new volume groups, so this won't happen again? Is there any reason I can't (or shouldn't)choose the maximum values for max_pv and max_pe_per_pv? Or, would it be better to pick a bigger extent size?

[Sanjay_6]

Hi Steven,

I would suggest you to increase the value of MAX PV and max PE per PV rather than a larger extent size unless you are storing files on this vg which are really big.

Maybe this link will help,

http://us-support.external.hp.com/cki/bin/doc.pl/sid=3d52e6e30acfcb63c3/screen=ckiDisplayDocument?docId=200000060285366

Hope this helps.

Regds

[Stefan Farrelly]

Leave MAX PE per PV the same. No reason to really change it from the default of 4 MB unless you have a large number of large disks in the VG in which case you may have to increase it. You can increase MAX PV up to the max though without any problem - we do on all our VGs here (all EMC).

[Trond Haugen]

The question if you don't want this to happen again is: how big do you anticipate the disks will get? And when will you use such a disk in that VG?
In my opinion with an EMC or XP disk-pool you will probably be able to create a new VG so it's probably not worth thinking about.
My short $0.02: Go for the default.

Regards,
Trond

[James R. Ferguson]

Hi Steven:

First, choose large values for 'max_pv' since you will want to be able to add more physical disk later.

Consider that 'max_pe' has a limit of 65535 extents and that 'pe_size' has a ceiling of 256. The product of these value is a very, very large volume group.

Whether you choose to inflate 'pe_size' as opposed to 'max_pe' or vice versa really only matters for extent-based striping, since the 'pe_size' then governs the size of the extent-strip round-robined among the physical disks.

Choosing large values for 'max_pe' and 'pe_size' that do not yield a "file too large" error during 'vgcreate' can be frustrating. The LVM allocation table mapping physical to logical extents needs to fit into one physical disk extent. Technical Knowledge Base document #KBRC00009036 offers some forumula to assist in determining values that will work.

Regards!

...JRF...

[Steven Hargus]

Stefan - I think you are thinking of the PE (physical extent) size.

[Steven Hargus]

Trond -
That's actually how we got into this situation. We were told everything would use a standard disk size of 5.4Gb, so we made our volume groups accordingly. Then, they ordered an EMC frame with bigger hypervolumes, and now they won't work with the existing volume groups. So, we are trying to prevent this from happening again.

[Sandip Ghosh]

I think you should use the max pe per pv as 20000. Because now the max size of a disk is 72 GB. So to accomodate that you have to keep it 20000. the value can go from 256 to 65536. It will not harm if you keep it in the larger size.

Sandip

[pap]

while creating VGs on new disks you have to select MAX PE_PV equal to
DISK SIZE in MB/PE

I do not think you can use random values for MAX PE per PV

Thanks,

-Pap

[Steven Hargus]

After reading Sanjay's linked document and doing some experimentation, I came up with the following table:

For the default extent size of 4Mb
------------------------------------

Max PV size Max PE/PV Max # of PV
16Gb 4096 116
32Gb 8192 59
64Gb 16384 30
128Gb 32768 15
~256Gb 65535 7

So, for smaller disk sizes, say 5Gb, I would want to choose max_pe_per_pv of 4096 and max_pv of 116, so I can grow the volume group by adding new disks. For large metavolumes, I am not as interested in adding more disks as I am adding large disks, so I would want to set max_pe_per_pv to the maximum (65535) and max_pv to 7.

[Wodisch]

Hi Steven,

actually we had that discussion already a couple of times, so search-ing for "+max_pv +mv_pe" or "vgcreate" should bring up those threads...
But to point you to something else: you would not like to use the theoretical limits without need, since then you waste a lot of RAM (in kernel) and have unneccessary big VGRAs and PVRAs (VG Reserved Area/PV Reserved Area), which could hurt you especially when using the "-v" option on the *display commands...
If the minimal(!) size of a replacement PV for your VG is expected to be at least 36GB, then you would try something like 5000 * 8MB or 2500 * 16MB or 1500 * 32GB or 1000 * 64GB or so, but not 9000 * 4MB, right? Imagine the output of "pvdisplay -v" on that PV...
And the amount of RAM needed to keep the map for that in your kernel (times the max_pv/vg, of course).
Since that map must fit into the first PE anyway, you'll need a bigger PE, though - and then you'll need fewer PEs, of course - so why not start with a reasonable (=manageable) mix form the very start.

HTH,
Wodisch