>> I scanned the documentation on this flag, and it's not a universally applicable setting. It should only be set in conjunction with a support case to address an identified issue. In general, it should only be set as a temporary measure, but there are exceptions to that general rule.
>>
>> On the whole, that issue appears to be related to transfer latency. That could be the latency of a slow network or the latency resulting from a network with a problem, such as packet loss. I'd imagine it could be also caused by latency imposed by an overloaded destination SATA aggregate as well, plus it's not out of the question that something newer like 40Gb Ethernet might create some kind of odd issue that warrants setting this flag.
>>
>> In normal practice, you shouldn't need to touch this parameter. I've been around a long time, and I'd never heard of it before now, and I've never used it with any of my lab setups, and I rely on SnapMirror heavily.
>>
>> The important thing is not to use this option unless directed by the support center. There's a risk of masking the underlying problem, or creating new problems.
>>
>> You might consider continuing to follow up on the case to ensure that either (a) you're in an odd situation where this parameter really is warranted or (b) there is some kind of underlying problem that needs fixing. If you're otherwise happy with the way the system is performing and the parameter change worked, I'd probably call it good...
>>
>> -----Original Message-----
>> Sent: Monday, January 30, 2017 12:30 AM
>> Subject: super secret flags
>>
>> Hi people
>>
>> Just out of idle curiosity, am I the only netapp admin who does not know about the super secret flags to allow snapmirror to actually work at reasonable speed?
>>
>> We were running 8.3.2 cluster mode, and spent weeks looking into why our snapmirrors to our remote site ran so slowly. We were often 2 days behind over 40G networks. Obviously, we focussed on network issues. And we wasted a lot of time. We could make no sense of the problem at all since sometimes it appears to work ok, the later the transfers slowed to a crawl.
>>
>> We eventually opened a case and it did not take to long for a reply which basically said "why don't you just disable the global snapmirror throttle."
>> I had already looked into such a beast, but found nothing.
>>
>> As you may or may not know, it turns out to be a per node setting. The name of the flag is repl_throttle_enable. Of course, you can only see such flags or change them on the node, in privileged mode.
>>
>> Setting the flag to 0 immediately (and I do mean immediately) allowed our snapmirrors to run at the speed you might expect over 40G. Instead of taking 2 days, snapmirror updates now took 2 hours.
>>
>> We have since upgraded to 9.1. The flags reverted to on, but again can be set to off. I think there is a documented global snapmirror throttle option in 9.1, but I have not looked into that yet.
>>
>> Are we the only site in the world to have seen this issue?
>> We use snapmirror DR for all our mirrors which may be a factor.
>>
>> As I said, just idle curiousity and maybe helping someone avoid the time wasting we had.
>>
>> Regards,
>> pdg
>>
>> Peter Gray Ph (direct): +61 2 4221 3770
>> Information Management & Technology Services Ph (switch): +61 2 4221 3555
>> University of Wollongong Fax: +61 2 4229 1958