vol move maximum concurrent.

[slender zinc]

So I've done some poking and individual testing.
Some resources point to a maximum volume moves at one time to 8, a few others state "it's resources dependent."

I've got a DR cluster that does almost 0 work that I've got nearly 2,500 vols I need to shuffle around at something besides a snails pace.

Is there a way I can kick the number of concurrent vol moves up a tick so I'm not doing this for the next month+?

It's a 10 node system. Four aggrs will be doing the heavy lifting of writing all of the moved data.

[dry sierra]

you can script this nicely using PowerShell. Get all volumes, start 8 moves, pause a minute and when the number of volumes moving is <8, start another one.

you really don't want too many concurrent volume moves. There's a reason for the limits (same as SnapMirrors)

[slender zinc]

I have a bunch queued, I'm not worried about keeping it fed with new work.

[slender zinc]

I respect that, a dormant DR system (no joke, 3 active CIFS sessions) will take a good deal of time still to move these with only 8 potential jobs.

[sick cloud]

volume move governor has a limit option that can be modified, default is 8.... if you have enough disks, you can surely set it to 20 or something

maybe turning off the deswizzler is also an option

just push all moves into the queue, they will be done sequentially, just make sure your aggregates do not run out of space

[slender zinc]

That's the command I couldn't recall. The moment I read Governor I recalled where it's burried.
Bumped the limit from 8 to 16 and am going to let the current moves finish out and try and adjust where the moves are feeding from/to to balance out the workload

[sick cloud]

I would recommend a number between 8 and 12 and see if the disk backend is maxed out.... if you have fabric pool, check if your s3 gateway is fast enough 😉

[slender zinc]

Luckily nothing there to worry about with this system yet.
Just going from old flashpool to non flashpool with NAE to check the box and restructure our data a bit for easier management.

System is slated for replacement in 12-18mo, but we just need to limp it along til then

[acoustic saffron]

Something you may want to try: enable diag mode. Then tab out the volume move start command. There is an option, I think it is bypass-throttling.

I would move fewer simultaneous volumes when enabling this.

[rare canopy]

     [-bypass-throttling {true|false}] - Bypass Replication Engine Throttling (privilege: diagnostic)
         This specifies whether this move should be throttled so protocol operations latencies are not affected by move. If this parameter is specified with true, the move will not be throttled by the transfer engine. The default setting is false. Note that this parameter
         does not affect the priority of the operation in relation to other operations in the system.

[sick cloud]

Is there a chance to enable diag mode and ro 0 with each login, just like a .bashrc? I want a dangerseeker Mode

[dry sierra]

not possible sadly. but depending on your SSH client you can automatically send commands straight after login

[dry sierra]

btw I would suggest using "rows 9999" instead of "rows 0". Has basically the same result, but doesn't screw up the columns in the output like "rows 0" does

[slender zinc]

Man I like those messed up columns some times, it's comforting at this point.

[slender zinc]

I was iffy on this at first but looking at OG1's output, it may be helpful in this rare situation.

[silk sentinel]

It bypasses BRE throttling. If there are zero frontend IOPS then it won't matter.

[slender zinc]

That's good to know.

I wish there was an aggressive evacuate or collapse command set

Vol move everything from aggr X to Y

Scripting gets I well enough, ah well.

[acoustic saffron]

yeah, but it feels good to put the option in there when you can 😁