On Mon, Mar 19, 2012 at 10:12 PM, Mathew Kilham
<matt.kilham@strattonfinance.com.au> wrote:
Hi Toasters,
I've posed the following question to NetApp support but wasn't too confident in the answer I received, so I was hoping the knowledgeable folks on this list could assist? Also, before I begin, please excuse any ignorance or NetApp faux pas on my behalf, I'm far from an expert at administering NetApp filers.
---
We have a FAS2050C running DOT 7.3.4. We recently added an external disk shelf to the filer and performed a bit of reorganisation, which has left us with two unused disks in the internal shelf. We want to add these two disks to an existing 16-disk aggregate by expanding it's RAID group size from 16 to 18. The aggregate is currently ~80% full and contains 5 flexvols, most of which have de-dupe and snapshots enabled.
I understand that after expanding the RG / aggregate we need to run a physical reallocate or else we will end up with a significant "hot spot" on the newly-added disks. I also understand that we need ensure DOT only does a physical redistribution of the blocks across all disks in the aggregate and does not try to otherwise rearrange them, otherwise we risk "un-deduping" our deduplicated data and/or greatly increasing the space consumed by our snapshots.
First question: I believe the command we need to run to perform the above style of reallocation is "reallocate start -f -p /vol/<volname>" - is that correct?
I noted, however, that there is a warning with regards to the "reallocate -p" command in the release notes of 7.3.x. Unfortunately I can't find a link anymore, but it reads:
"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. Since a file reallocation scan does not predictably improve read performance when used on deduplicated volumes, performing file reallocation on deduplicated volumes is not recommended. Instead, for files to benefit from the reallocation scan, they should be stored on volumes that are not enabled for deduplication."
I then queried with NetApp how we could perform a physical reallocate on the aggregate to avoid a hot spot, given the above statement that "reallocate start -p does not rearrange blocks that are shared between files by deduplication on deduplicated volumes", and almost all of our data is deduped.
After a bit of to-ing and fro-ing with NetApp, the final suggestion was as follows:
"I’ve talked to two senior resources so far about this. The suggested steps are as follows>>
#1: add your disks to the aggregate, and then grow the volume.
#2: Turn off Deduplication, ( no, this will not revert to the 2.5 gigs from the one gig ratio it is now and suddenly cause you to be out of space) this will only stop deduplication from this point forward until it is re-enabled later. Everything that is currently deduped will stay the ratio it is.
#3: Perform the reallocate –p command as specified in the KB’s sent earlier.
#4: After all above steps are performed and reallocate is done, re-enable deduplication on said volumes."
Second question: Does this sound kosher - will this actually result in a physical reallocate being performed, or will the deduped blocks still be skipped because they're already de-duplicated, regardless of whether dedupe is enabled for new data on the volume or not?
Third question: If yes to the previous question, is there any risk that our deduped data get un-deduped by performing the suggested steps above?
Fourth and final question: Is there any way to measure how data is spread across disks in a Raid Group / aggregate, so that I can check that we get our expected results from the reallocate?
Thanks everyone, really appreciate any feedback / assistance.
Cheers,
Matt
_______________________________________________
Toasters mailing list
Toasters@teaparty.net
http://www.teaparty.net/mailman/listinfo/toasters