NetApp Technology Network: Message List - dedupe causes vol size to grow

Re: dedupe causes vol size to grow

community@netapp.com — 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).

Re: dedupe causes vol size to grow

sarbjit@netapp.com — 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

community@netapp.com — 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

community@netapp.com — 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

sarbjit@netapp.com — 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

community@netapp.com — 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

community@netapp.com — 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

community@netapp.com — 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

sarbjit@netapp.com — 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

community@netapp.com — 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