Default max PE - any methodology changes coming?

[Tim Malnati]

With the amount of inquiries in this forum and others, it is clear that the default max PE is a real problem that should be addressed by the Lab. With drive sizes constantly increasing, I would think that the default would be better suited toward allocating this parameter for the largest drive size that is currently available for purchase. In many cases this would mean some lost drive space, but the confusion and work required to upgrade the drive size in a volume group more than offsets any perceived costs, and an administrator could always reduce it initially if this space is a concern. My thought here is that down the street maintenance reduction should be more of a goal with system defaults. Otherwise, I would think that a Lab change to this would not take much longer that it did for me to write this post.

So... Is anyone in the Lab listening?

[Cheryl Griffin]

Tim,
Keep the feedback coming because HP is listening.

I did some digging into some open issues with vgcreate and found that some changes are being made.

* The Ignite-UX product starting at version 1.49 has upped the default max_pe value from 2000 to 2500.

* Preloaded systems that are ordered from HP will also start having the default value set to 2500.

I would like to see the feature where you can change max_pe on-the-fly!!

Best Wishes,
Cheryl

[Andy Monks]

To be fair, vgcreate does automatically adjust the max PE size to that of the largest disk when you create the volume group.

Also, there are some other limits (non-lvm) which would have to be addressed.

You can now also get VxVM for hp-ux, which may already do this. Checkout the veritas web page for info.

[Tim Malnati]

Andy, I'm not sure you got my point. What I'm suggesting is that if HP is currently selling 18 gig drives, then the software should default for max_PE that will satisfy this drive size, NOT that you actually have 18 gig drives in the group you are creating. My thinking is that although you may not have them installed in your machine now, there is a good chance that you may opt for them in the future (or may not have the choice) when room becomes an issue (seems more a matter of when than if). Even if you lost 50 meg of space on the drive, it's worth it in the long run if you ever need to add a big spindle to the group. Sure beats backup - rebuild - restore or worse if it's the root vg.

Veritas may have an answer, but this is NOT an answer that HP customers expect when they are already paying big bucks for support and add on products like Online JFS.

[Andy Monks]

The downside of creating the vg structures as big as you might physically ever require, is that they use space on the disk and physically memory which will never get paged out. Therefore assuming maxvgs set to 10 (the default), you could quite easily use 320mb of physical memory on lvm structures. Are you sure you want to do this?

[Jason Luginbuhl]

Andy Monks makes a good point. The HP Labs are really between a rock and a hard place on this one. If they make the default Max PE Per PV too large then those customers which take the default value will waste too much disk space on the LVM header tables that are created in the VGRA of each disk in the vg. If they make it too small, then customers who want to add large disks to existing volume groups containing smaller disks will not be able to based on this restriction.

The bottom line is that the Max PE per PV and Max PV parameters are necessary because LVM uses them to setup the default table size that each disk in the vg will use to keep track of each extent of all the disks that could be added into the vg. This is a necessary functionality for how LVM works. For a more detailed description of Max PE per PV restrictions, you may want to take a look at the Knowledge Base Document KBRC00000244.

[Tim Malnati]

If everything that I have read so far is accurate, it would seem to me that the Lab has some work to do in order to handle the future disk growth that is sure to come. What I'm seeing here would suggest some real problems attempting to fully dress out a V series box. Is there an documentation out there that explains the format of the VGRA and how LVM is handled in memory in detail?

From what I'm reading here suggests that the VGRA is duplicated on each physical disk within a volume group. This makes little sense to me, particularly where this information is loaded resident to memory anyway. I would hope that the LVM tables loaded to memory would be somewhat dynamic. If not, a lot of memory is being wasted for potential growth. It was my understanding that maxvgs controlled the quantity of volume group communication channels available. Does an increase from say 10 to 20 mean that memory usage for LVM tables will double? If all of this is true, I would suggest that Cheryl's comment will be the way that the Lab will need to go real soon. I suppose as a stop gap they could increase the default PE size upward, but this would buy little time the way I see data warehouse machines growing.

[Dave Wherry]

I think everyone is making good points here. What probably started this for Tim is what has happened to me and judging by the posts in the forum here, a very high percentage of other Sys. Admins. We inherited systems set up by some one else and are now getting stuck with a bunch of volume group rebuilds to accomodate newer, larger disks. Or maybe we did it to ourselves because we were not aware or did not learn from the past.

In any event I've been burned by it and am accutely aware of it. My personal choice is to bump max pe up higher than the default and live with the overhead it creates.

It's currently not as big of an issue for me as I am using an XP256. No matter what size drive I put in there, it gets carved up into the same size LUN (Open-8) each time. Where it could become a problem again is if I end up using all of the allowable LUN's on an interface. I saw this at the last place I worked with an EMC frame. Maybe someday I will have to use LUSE and combine 2 or more LUN's into a larger one. To handle that I have already set max pe to double the size of an Open-8 LUN. It does not cover all possibilities, but, it may help in the future.

My point is I do not think there is a blanket answer for every site. Some lower end boxes may not be able to afford the overhead. Mine can. It is probably better for HP to error on the lower side. Tim suggested HP start high and we Admins. lower it. I think HP needs to protect the less experienced Admins. and keep it low. Then more experienced Admins. need to be aware of the pitfalls. Tweak up and grab resources rather that having to lower and free up resources. If by default it was too high and negatively affected performance we would be in the same situation of having to rebuild.
Being too low is an inconvenience. Being too high can hurt. Besides, it may not be exciting work, but, it keeps us employed.

[Dave Wherry]

I forgot, Cheryl - "change max pe on the fly".
YES! YES! YES!
I got the Interex Survey on enhancement requests. Frankly, some of the stuff was pretty lame. On the fly volume group changes or even in single user, as Tim said sure beats backup, rebuild and restore. Those are the types of enhancements HP should focus on.

[Andy Monks]

Well, to see what the future holds checkout :-

http://www.veritas.com/us/products/volumemanager/