I am implementing a mass change in alert thresholds for volumes based on their size, and then turning AutoGrow on for all of them. As I've been updating thresholds, I suddenly noticed an unexpected result on a volume that already has AutoGrow enabled.
Specifically: OCUM (6.3, for cdot) shows the "nearly full" and "full" thresholds in the Capacity tab based on the potential size of the volume if it AutoSized to it's maximum size, not based on it's actual size. Does anyone know if this is a bug in OCUM or if it is accurate? If it is accurate, is there a way to override this behaviour? And does it work the same way in OCUM 5.x for 7-mode?
To give a specific example: I have a volume that is 500GB in size with AutoGrow turned on. Max potential size via AutoGrow is 600GB.
The Nearly Full Threshold, set at 92%, shows as 552 GB, 52 GB larger than the volume's current size! The Full Threshold is set at 96% and shows as 576 GB. Clearly it is basing the % on the potential size and not actual.
I am hoping this is an OCUM bug and that in reality it bases the thresholds on the actual size. Anyone know for sure?
Just to update this thread, I have been informed that this is the expected behavior of OCUM 6.x! This is not considered a bug. They have changed the alerting mechanism so it alerts based on the potential size of a volume with AutoSize turned on, not based on the actual size. To say this least, this is unintuitive, especially since it wasn't documented anywhere, and considering the fact that OCUM 5.x did not operate this way. I just verified this morning that OCUM 5.x works as you would expect - it alerts based on actual volume size. I have requested in my NetApp ticket that OCUM 6.x be updated to allow this new "feature" to be turned off. It has completely messed up a project I was in the middle of to turn Autogrow on system-wide and change alert thresholds.
I confess I don't understand how OCUM 9.5 is coming out and there is still no fix for this bug. At least it is documented now, but no list of versions where it will be fixed. This is such a basic feature of a storage product that I would have thought it would be corrected around 2 1/2 years ago when it was first reported.