Can a deduped volume grow beyond the max. deduped volume size if dedupe is disabled?

[cschnidr]

Hi all,

If I have a volume as big as 16TB which is deduped, can I transfer that volume to a 64bit aggr (with dedupe enabled) and grow that volume later beyond 16TB (with dedupe disable) without undoing the deduplication?

Thanks

Christoph

[aborzenkov]

I would tentatively say “yes” for Data ONTAP 8.1. Here you could VSM from 32 to 64 bit which effectively converts target to 64 bit volume retaining deduplication.

Otherwise you would have to do QSM (or similar) which first un-deduplicates data. So you will need to deduplicate target again.

As long as we mention 8.1, easier route could be to simply grow source aggregate beyond 16TB limits, thus getting 64 bit deduplicated volume in place.

[cschnidr]

For DOT 8.1 the max vol sizes for dedupe/compression equals the max size of the volumes. So problem away. My question is about DOT 8.0.2x land only.

[aborzenkov]

Sorry, I overlooked “dedupe disabled”, but the answer is the same – any possible method of moving data from 32 to 64 bit will effectively undo deduplication in 8.0.x.

[cschnidr]

Thanks for your prompt replies. I think I have to rephrase my question.

Here I what my customer tries to do:

1. QSM a 14TB volumt to 64bit aggr

2.Dedupe (potentially also compress the new vol)

-> now the question, what happens if the volumes needs to grow beyond 16TB (on DOT 8.0.x).

can we disable dedupe/compression and just expand it to lets say 20TB?

[aborzenkov]

I doubt it will work for two reasons

1. If you have 16TB deduplicated volume and copy it to 64 bit aggregate effectively undoing deduplication you are likely to end up with volume exceeding 16TB in the first place. So no further dedup will be possible.

2. Turning dedup off (“sis off”) still leaves volume deduplicated; it just prevents new data from being subject to fingerprint computation. So 16TB limit still applies.

[cschnidr]

I'm fully aware that the dedupe will be away after QSM. We will dedupe it on the destination too.

I'm not able to follow your logic in 2. I believe that the dedupe limit is based on the fingerprint db, that cannot hold changings larger than a certain amount an not the internal volume structure.

I believe this question needs to be answered by product ops.

[radek_kubka]

I know I am stating the obvious, but if this is important why not upgrade to 8.1?

[cschnidr]

Sorry, if this would be possible I wound't obviously ask this question here.

[vreddypalli]

Hi,

I have done a small test on one of the filer

host:~> ssh filername version

NetApp Release 8.0.2P2 7-Mode: Tue Aug 16 08:11:45 PDT 2011

Created a volume of 24T and tried enabling the deduplication

---------------------------------------------------------------------------------------------------------

host:~> ssh filername vol create test_dedupe_vol -s none aggr2_64 24t

Creation of volume 'test_dedupe_vol' with size 24t on containing aggregate

'aggr2_64' has completed.

host:~> ssh filername sis on /vol/test_dedupe_vol

Volume or maxfiles exceeded max allowed for SIS: /vol/test_dedupe_vol

----------------------------------------------------

Resized the same volume to 16TB and tried enabling the deduplication

host:~> ssh filername vol size test_dedupe_vol 16t

vol size: Flexible volume 'test_dedupe_vol' size set to 16t.

host:~> ssh filername sis on /vol/test_dedupe_vol

SIS for "/vol/test_dedupe_vol" is enabled.

Already existing data could be processed by running "sis start -s /vol/test_dedupe_vol".

In your scenario if the volume size is exceeding 16TB after performing a QSM it may not be possible to enable and run the deduplication on the new destination.

-Vijay