Hi Mike, Fletcher & the toasters list,

 

> This should explain everything about reallocation, have fun.

 

Thanks for the document. I have read it before, but it's been updated since the last read, so I had a look over it again.

 

The latest version now says:

 

"4.4 DEDUPLICATION AND COMPRESSION

Starting in Data ONTAP 8.1 deduplicated data can be reallocated using physical reallocation or read_realloc space_optimized. Although data may be shared by multiple files when deduplicated, reallocate uses an intelligent algorithm to only reallocate the data the first time a shared block is
encountered. Prior versions of Data ONTAP do not support reallocation of deduplicated data and will skip any deduplicated data encountered."

 

Bearing in mind we're on 7.3.4 this just serves to reinforce my suspicion that the criteria for reallocate to ignore deduplicated data is whether each individual block is already deduplicated, not whether dedupe is currently enabled for the volume or not. Hence, if I'm correct, the suggested procedure from NetApp won't help us as any existing deduped data will simply be ignored (meaning basically none of our data will be reallocated).

 

Does anyone have any information to the contrary - any information suggesting that I'm wrong?

 

The big issue for us is that we can't test this - by the time we find out if the reallocate does what we want it to do we will already have grown the aggregate, and from what I understand there's no "going back" at this point.

> I had a case open with Netapp and the engineer came back with this:

>

> Data ONTAP® 7.3 System Administration Guide:
> https://now.netapp.com/NOW/knowledge/docs/ontap/rel7351/pdfs/ontap/sysadmin.pdf
> 
> What a reallocation scan is, Page 315
> 
> “A file reallocation scan using reallocate start or reallocate start -p does
>  not rearrange blocks that are shared between files by deduplication on
>  deduplicated volumes. Because a file reallocation scan does not predictably
>  improve read performance when used on deduplicated volumes, it is best not to
>  perform file reallocation on deduplicated volumes. If you want your files to
>  benefit from a reallocation scan, store them on volumes that are not enabled
>  for deduplication.”

 

Thanks. More contradictory information from NetApp though unfortunately :-( The start of that paragraph again sounds to me like the criteria is whether a block is currently deduped or not, but then the last sentence specifically says "...on volumes that are not ENABLED for deduplication".

 

Any of the NetApp engineers on this list care to throw in their two cents?

 

 

> We ended up reallocating (in effect) when we upgraded to 8.1 using data motion to migrate to fresh aggregates (btw 2 clusters)

 

I'd love to be able to do it this way, but we don't have the spare disks to be able to create a new aggregate and then move our data to it.

 

As a fallback, we could /maybe/ shuffle data back and forth between a second existing aggregate and the first aggregate (the one we want to expand). I assume this would have something like the effect of physically reallocating the blocks as the data is moved back to the primary aggregate? Would be a giant PITA though.

 

> But I'd be interested to know if you get a different answer (and net benefit  from reallocation on a dedup'ed volume)

I'll certainly let the list know what the final outcome is, if any.

 

 

Cheers,

Matt