topic Re: Volume Autosize Bug in Software Development Kit (SDK) and API Discussions

Volume Autosize Bug

michael_england — Wed, 04 Jun 2025 19:34:41 GMT

I'm actually not entirely sure this is a bug, but it is a bit annoying. I'd like to set both the shrink and grow autosize threshold at the same time but it doesn't seem to be working. Take the following example:

request = new NaElement("volume-autosize-set");

request.addNewChild("volume", volumeName);

request.addNewChild("mode", "grow_shrink");

request.addNewChild("shrink-threshold-percent", "84");

request.addNewChild("grow-threshold-percent", "92");

request.addNewChild("maximum-size", maxVolSizeGB+"g");

request.addNewChild("increment-size", "50g");

Now if I run this against a volume that's <20GB in size the defaults are grow at 92% and shrink at 85% so it'll work fine. However, if I run this against a volume >4TB, the defaults are grow at 98% and shrink at 93% and it throws the following error:

Reason: Autosize grow threshold must be larger than the shrink threshold. (errno=160)

So, even though I'm asking to change both of them at the same time, something internal is asking for the grow threshold to be set first which conflicts with the shrink. My workaround is to set the shrink value first, then make a second call for the grow. Is this expected behavior?

I should also note that, indeed changing them at the same time works fine, as long as they don't overlap with the volume defaults.

Re: Volume Autosize Bug

bobshouseofcards — Thu, 11 Aug 2016 03:15:23 GMT

Hi Michael -

You've described it perfectly. Despite you chaning multiple values in a single call, each is changed individually and each must meet the various checks and rules as they go, as opposed to having a starting state, and ending state, and checking whether the entire ending state is valid then applying the ending state. This latter description is what you want, but it's the former that the DoT uses. You just have to be aware of it and process accordingly. Consider it a "feature".

With respect to what gets changed first, hard to say. I've tended to assume alphabetical order of parameter, and I haven't seen or experienced anything to indicate a different order.

Autosizes are fun. Another example would be if you are adding compression to a previously uncompressed volume. If a volume is near it's size limit (despite having an autosize) the space efficiency job can fail based on an estimate of the actual space available and snapshot size needed. So you fake it by increasing size, starting the job, and immediately decreasing volume size. Why could not the autosize limit be taken into account? Would seem natural sure, but it just isn't. So we work around such behaviors.

Hope this helps.

Bob Greenwald

Senior Systems Engineer | cStor

NCIE SAN Clustered, Data Protection

Kudos and accepted solutions are always appreciated.

Re: Volume Autosize Bug

michael_england — Thu, 11 Aug 2016 17:52:36 GMT

Thanks very much for your prompt response and explaination.