topic Re: Volume resize behavior with dedup in ONTAP Discussions

Volume resize behavior with dedup

shashidhargc — Thu, 05 Jun 2025 06:08:14 GMT

Below is the scenario on which my question is based on:

Data Ontap version 7.3.3 on FAS2040

· FlexVol of 800GB is created with guarantee=VOLUME and fractional reserve=0 .
· Two LUNs of 300GB each are created on the volume with SPACE RESERVATION=ENABLED.
· Dedup is enabled on the volume.
· User decreases the volume size to 132GB.

So my question is how did Data Ontap allow the user to reduce the volume size to 132GB when there are 2 X300GB SPACE RESERVED LUNs(600GB)on the volume. It should have allowed to reduce the size only upto 600GB.

My possible guesses are it may be a bug or due to the fractional reserve set to 0.

Need inputs.. Please help..

Thanks in advance..

Re: Volume resize behavior with dedup

radek_kubka — Thu, 07 Mar 2013 10:40:12 GMT

Hi,

What's the output of df -s your_vol_name ?

I'd say it's expected behaviour if LUNs got significantly deduped.

Fractional reserve is a slightly different kettle of fish and setting this to 0 doesn't explain this on its own.

Regards,
Radek

Re: Volume resize behavior with dedup

shashidhargc — Thu, 07 Mar 2013 10:54:20 GMT

Filesystem used compressed a-sis %saved

/vol/SATA_ABGCLUSTER_Onstream/ 135548488 0 495568600 79%

Apart from Dedup, i guess fractional reserve also has imporatant role here, because as fract reserve is set to 0, all free blocks after dedup are returned to the volume free pool.

Re: Volume resize behavior with dedup

radek_kubka — Thu, 07 Mar 2013 11:13:47 GMT

Nice one, so it is deduped to roughly 132GB.

Deduped blocks are returned to the volume regardless of the fractional reserve setting. If it is set to 100, instead of 0, you wouldn't be able to shrink the volume under 2x 132GB (or thereabouts with many, many other caveats )

Re: Volume resize behavior with dedup

shashidhargc — Thu, 07 Mar 2013 11:34:09 GMT

Please refer the attached doc on Configuring NetApp Deduplication with LUN’s.

Currently we are following Configuration C (as per doc).. where FR=0 and hence freed blocks are returned to the volume free pool. So used space on volume decreases are dedup irrespective of the LUN size. And hence allows volume to shrink.

In configuration A & B show that varying FR value returns freed blocks to Fractional Overwrite reserve and hence i guess LUNs will remain space reserved.

I just tried these on my simulator and got similar results.. Thus hoping this is it.

Re: Volume resize behavior with dedup

radek_kubka — Thu, 07 Mar 2013 11:43:53 GMT

OK, I stand corrected - it basically means that Scenario A (FR=100, both volume & LUN thick provisioned) is not a good fit for dedupe:

"The advantage of this configuration is that snapshots will consume less space when blocks in active file system are no longer being used. As a result, this volume will be able to hold more snapshots."

But there will never be any space savings within the active file system.