topic Re: dedupe causes vol size to grow in ONTAP Discussions

dedupe causes vol size to grow

sarbjit — Thu, 05 Jun 2025 07:26:38 GMT

IHAC who are using FAS3020 running ONTAP 7.2.5.1.They enabled dedupe on a volume of 30GBwhich is not space reserved and the fractional reserve is set to 100%.The volume has a LUN of 25GB.

After enabling dedupe,customer saw the volume size increasing and it reached to a max autogrow limit of 60GB.Customer then disabled dedupe.(I believe they did using sis stop/sis off commands which saves the current fingerprint information) as the aggregate was also running out of space.

BEFORE dedupe AFTER dedupe

Vol->30GB vol-->60GB

lun->25GB lun->25GB

## vol options ##

SCCM online     raid_dp, flex     nosnap=off, nosnapdir=off,
                           sis               minra=off, no_atime_update=off,
                                             nvfail=off,
                                             ignore_inconsistent=off,
                                             snapmirrored=off,
                                             create_ucode=on,
                                             convert_ucode=on,
                                             maxdirsize=20971,
                                             schedsnapname=ordinal,
                                             fs_size_fixed=off,
                                             guarantee=none, svo_enable=off,
                                             svo_checksum=off,
                                             svo_allow_rman=off,
                                             svo_reject_errors=off,
                                             no_i2p=off,
                                             fractional_reserve=100,
                                             extent=off,
                                             try_first=volume_grow,
                                             sis_logging=off,
                                             read_realloc=off
                Containing aggregate: 'aggr0'

#sis status -l shows the volume as :

Path:                    /vol/SCCM
State:                   Disabled
Status:                  Idle
Progress:                Idle for 30:11:29
Type:                    Regular
Schedule:                auto
Last Operation Begin:    Wed Jun 24 12:08:00 IST 2009
Last Operation End:      Wed Jun 24 12:23:00 IST 2009
Last Operation Size:     25 GB
Last Operation Error:    -
Stage:                   Done
Fingerprints Gathered:   6554516
Gathering Begin:         Wed Jun 24 12:08:00 IST 2009
Fingerprints Sorted:     6554516
Duplicate Blocks Found: 784739
Sorting Begin:           Wed Jun 24 12:17:39 IST 2009
Blocks De-duplicated:    784876
De-duping Begin:         Wed Jun 24 12:18:16 IST 2009
Fingerprints Deleted:    0
Checking Begin:          -

How can we reclaim the grown space in the volume?Is it because of the fingerprint information & checkpoints?can we delete the fingerprints and start a fresh dedupe using "sis start -s"

Do a deletion of fingerprints and "sis undo" the volume first before starting it all over.

Any inputs will be highly appreciated.

best regards

sarbjit

Re: dedupe causes vol size to grow

aarondelp — Thu, 25 Jun 2009 15:28:21 GMT

Did they have snap shot on the volume? Best practice is to remove all snapshots on the volume prior to dedupe.

Although I'm not entirely sure why your volume would have grown (somebody here may have an idea as to why).

Aaron

Re: dedupe causes vol size to grow

sarbjit — Thu, 25 Jun 2009 15:30:34 GMT

No snapshots on this particular volume :

##snap list from asup##

Volume SCCM
working...

No snapshots exist.

Re: dedupe causes vol size to grow

jooss — Thu, 25 Jun 2009 16:45:00 GMT

Do you have LUN reservations enabled?

If you disable LUN reservations, I believe, the space will not be consumed.

Re: dedupe causes vol size to grow

radek_kubka — Thu, 25 Jun 2009 17:08:59 GMT

Rick,

From Sarbjit's post it looks like the fractional reserve is indeed set to 100%.

But we were alwas told that fractional reserve kicks in only if there is at least one snapshot in the volume in question. And apparently in this case there are no snapshots.

Is A-SIS taking a 'hidden' snapshot which causes this behaviour?

Regards,
Radek

Re: dedupe causes vol size to grow

sajan — Thu, 25 Jun 2009 21:01:18 GMT

Sarbjit,

I beleive in this case the overwrite resreve space is going up by 30 GB (100% - value for fractional reserve). Since volume gurantee is none,

there will really be no physical storage allocated for this overwrite space. So, in sumamry we would not consume any extra space in this

configuration. We can confirm this if you could provide the output of "df -r"? If the overwrite reserve space is 30 GB and it is shown in parentheses then it conforms this theory.

Radek,

If the guarantee is "volume/file" then enabling dedupe is like taking a snapshot on the volume from a fractional reserve perspective. And the reson for that is one can overwrite deduplicated data with undeduplicable data.

Dedupe does not create snapshot except in one case - when "sis start -s" is run to deduplicate the data writtent on a volume before enabling dedupe. In this

case we create a temporary snapshot and delete it once the dedupe operation (sis start -s") is done.

regards,

-Sajan

Re: dedupe causes vol size to grow

sarbjit — Fri, 26 Jun 2009 00:48:26 GMT

thanks to all for replying on the post!!

###df -r output###

/vol/SCCM/ 62914560 49680084 13234476 (26269580) /vol/SCCM/
/vol/SCCM/.snapshot 0 0 0 0 /vol/SCCM/.snapshot

/vol/SCCM/sccm.lun          25.0g (26847313920)   (r/w, online, mapped)
                Comment: "SCCM"
                Serial#: C4iBFJL-Fj4r
                Share: none
                Space Reservation: enabled (not honored by containing Aggregate)
                Multiprotocol Type: windows

This seems to be inline with Sajan's comments.The question is how do we get back to the original state?(when the vol was 30GB and LUN was 25GB)?How can we reclaim the space taken by the space reserved LUN(assuming there were changes in data on the LUN which caused the volume to grow) and now those blocks are locked by the storage.

What is the best way to reclaim this reserved space without actually disabling LUN space reservation?I believe we can use snapdrive 5.0 to reclaim the space that is locked on the storage.

thoughts/comments?

Best Regards,

sarbjit

Re: dedupe causes vol size to grow

sajan — Fri, 26 Jun 2009 01:30:19 GMT

Sarbjit,

As mentioned before there is really no physical storage reserved for overwrite and space saved by dedupe is available to the aggregate (It may not

show in DF -A though).

Regards,

-sajan

Re: dedupe causes vol size to grow

jooss — Fri, 26 Jun 2009 02:10:30 GMT

Hi,

There's no hidden snapshot but when the volume is dedup'd and there are space reserved objects (typically LUNs are the only space reserved object but it also possible to enable space reservations on files) the space will be reserved.

If you disable reservations on the LUNs, which generally makes sense when using dedup, you should see the space returned.

Also, as mentioned in this case the volume guarantee == none and because of that even though the space is "reserved" at the volume level no physical blocks at the aggregate level are being reserved.

Re: dedupe causes vol size to grow

sarbjit — Fri, 26 Jun 2009 02:31:33 GMT

thanks to all for the quick reply.

Much Appreciated!!!

Best Regards

sarbjit

Re: dedupe causes vol size to grow

amiller_1 — Fri, 26 Jun 2009 21:49:30 GMT

Just to chime in way after the fact, I have actually seen the "temporary" asis snapshot in place during the initial dedup run and then disappear after the fingerprints have been created..

If you want to realize dedup space savings, you'll need to use thin provisioning regardless (i.e. no volume or LUN space reservation).