dedupe causes vol size to grow

IHAC who are using FAS3020 running ONTAP 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,
                                             guarantee=none, svo_enable=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


Re: dedupe causes vol size to grow

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).


Re: dedupe causes vol size to grow

No snapshots on this particular volume :

##snap list from asup##

Volume SCCM

No snapshots exist.

Re: dedupe causes vol size to grow

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


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?


Re: dedupe causes vol size to grow


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. 


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.



Re: dedupe causes vol size to grow

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.


Best Regards,


Re: dedupe causes vol size to grow


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).



Re: dedupe causes vol size to grow


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

thanks to all for the quick reply.

Much Appreciated!!!

Best Regards