2009-06-25 08:14 AM
IHAC who are using FAS3020 running ONTAP 18.104.22.168.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 options ##
SCCM online raid_dp, flex nosnap=off, nosnapdir=off,
sis minra=off, no_atime_update=off,
Containing aggregate: 'aggr0'
#sis status -l shows the volume as :
Progress: Idle for 30:11:29
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: -
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.
2009-06-25 08:28 AM
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).
2009-06-25 10:08 AM
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?
2009-06-25 02:01 PM
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.
2009-06-25 05:48 PM
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)
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.
2009-06-25 06:30 PM
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).
2009-06-25 07:10 PM
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.