2011-11-18 12:47 PM
I'm pretty sure you can't do this, so the question I have is what you do to reallocate the volumes when you add a bunch of new disks to the aggregates the disks reside in. Normally, I'd run a full reallocate to redistribute the data across the new disk. However, I can't run a reallocate on a SM destination. I get the obivous error stating the volume is read-only. This makes sense to me, but at the same time I'm at a loss for solution.
The only thing I can think of is to do the following:
1) Break the mirror.
2) Reallocate the volume.
Is there an easier or better solution than this?
2011-11-24 01:05 PM
You have to break the mirror. But be careful, your snapshots will grow, probably very much so, since everything is locked in a snapmirror destination, with at least the snapmirror snapshot. You are better off mirroring it again, and then syncing that mirror to the original source (we do this all the time) which should give you effectivly the same result (unless you have a really full aggregate).
I do have to ask the question.. Why?
2011-11-24 01:21 PM
agreed...if managable over the wan to reinit that might be less painful, but depends on the volume size and if you can go without the mirror for a while (but you will go without it during reallocate as well). ONTAP 7.3+ added a physical reallocate (reallocate -p) of a volume so that volume snapshots don't expand on reallocate, but you still should delete aggr snaps for that reason since the aggr snap will grow if they exist. But if 7.3 or higher you could reallocate -p after deleting aggr snaps and breaking the mirror then you won't take extra space on reallocate.
There is also the caution if you run asis...if you run asis then don't run reallocate without checking with support and current issues and burts with that.
2011-11-28 06:11 AM
That's what I figured, though I had not considered remirroring. In my case, it would probably take less time to break the mirror then reallocate.
My primary reason was curiousity. The other concern is since I added a ton of disks to my SM Destination aggregates recently, it makes sense to want to take advantage of those spindles in the event we have to fail over to our DR site.
2011-11-28 06:13 AM
We always to reallocate -p, as the vast majority of our volume set is in a Snapmirror relationship and I want to avoid generating all of the extra change. We don't do aggr snapshots, so that shouldn't be an issue. I exclude any deduplicated volumes from my reallocation run processes, as I've read of similar issues.
Thanks for the replies!
2011-12-15 06:02 PM
Here is a question I had before: Why? Snapmirror performance over the WAN is noting compared to even a small aggregates performace. You would be very hard pressed to push disk I/O limit on a local LAN much less a WAN. I suspect you may be doing something for no reason. It does not matter that you added disks, those disks can give you the I/O back faster than snapmirror can send it to the destination.
2011-12-16 11:07 AM
I would never be accessing disk over the WAN link. We are an FCP only shop at this point, so we don't access disk an further away than we can run a fiber cable. The reason I'm concerned about the SM Destination performance at all is because it's our failover site. The idea is that in an extereme situation we need to be able to get back and up on our feet at this facility, and I would prefer to have the disk performing at maximum capacity when that happens. Right now, it will not because the new spindles I've added will not be utilized. I'd prefer deal with the situation now when I can plan and execute it at my leisure than scramble during an actual emergency.
2012-02-24 12:54 AM
The reallocate family of commands manages the allocation, or layout optimization, of large files and LUNs on a filer. Additionally all files in a volume may be reallocated, and the block layout of aggregates may be optimized. Using the reallocate command, layout measurement and optimization (reallocation) can be automated.
The automated allocation management process consists of three main steps:
1. Measure the current layout. If the optimization is less then a threshold value then take no action. This step is optional.
2. Perform reallocation.
3. Measure the layout again. If the optimization is above the threshold value, repeat steps 2. and 3. as necessary.
*Good FRIENDS are hard to find, harder to leave, and impossible to forget*
2012-02-24 05:19 AM
Hi, thanks for the response. I'm very familiar with the reallocate command and it's use. The problem is reallocating Snapmirror destination volumes. Since SM Destinations are read-only, this presents an issue. I wanted to see if anyone else ran into and addressed this issue in some way I was not aware of.
2012-02-24 06:19 AM
Are you using DFM or OnCommand? If yes, Did you try using secondary space management wizard for migrating secondary volumes?