Thank you all for the comments. The result will be to leave the settings are is and the to change the snapmirror schedule to ondemand, so that process can complete, an each time reduce the snapmirror ondemand trigger
Again thanks and how someone else found this helpful in there struggles. /Mike
-----Original Message----- From: toasters-bounces@teaparty.net [mailto:toasters-bounces@teaparty.net] On Behalf Of Michael Bergman Sent: Wednesday, June 24, 2015 6:58 PM To: Toasters Subject: Re: Deswizzle
John Clear wrote:
As others have mentioned, you want to let deswizzling finish. You can tune the priority of the deswizzling process with 'wafl scan speed' to limit the impact of the scan.
Actually wafl scan speed is a global cap type of knob.
wafl scan speed is auto tuning (by setting it to 0 'zero') and turning it down lower than the 1300 or so that the auto tuner does anyway, probably isn't what you want in the general case. YMMV, depending on the size (model) of FAS machine this is.
There's a longer discussion here, but I believe it might be possible to fine tune the prio of the deswizzler scanner -- I'm not sure though I'm afraid. There are lots of "secret" knobs that are in theory turnable for various types of scanners, but it's not documented. Basically it's the teams that author or maintain the code that know what those knobs might do, but they are usually not experienced w.r.t. field workloads and hence cannot really give good advice on what way to turn the knobs
Now, disabling the deswizzler is easy, it's a global (hidden) option, once set it's visible:
"options wafl.deswizzle.enable off" will terminate any running deswizzlers so manually aborting them should not be necessary. "options wafl.deswizzle.enable on" will start the deswizzler on any volume that has swizzled blocks.
As long as this option is "off" the deswizzling will be done inside WAFL, on-the-fly, when data is read basically. This will of course slow access down somehwhat, at least on the first access. Depending on the power of your controller (the size of it) and the workload, this may be better for you, it depends.
I can say that when we Vol SnapMirrored billions of files from 100s of FlexVols 7mode -> C.DOT, the target system (all FAS8080) had wafl.deswizzle.enable off by design from day one. They still have. We have heavy workload, random R & W it's a sandstorm. Bogging the controllers down in s-Kahuna (before 8.3) with a bunch of basically never ending deswizzler scanners, is of no added value for us with the amount of cache and FlashPool we have
In 8.3 and onwards the deswizzler is in Waffinity, the VOL Affinity to be exact. So it's much more parallelised in 8.3 than before. OTOH it can make VOL become busier than you'd like... sure it's bg type work but it's there and it can disturb things w.r.t. user workload even if your're good on CPU cycles
Hope this helps some ppl at least!
/M -- Michael Bergman Sr Systems Analyst / Storage Architect michael.bergman at ericsson dot com -- This communication is confidential. We only send and receive email on the basis of the terms set out at www.ericsson.com/email_disclaimer _______________________________________________ Toasters mailing list Toasters@teaparty.net http://www.teaparty.net/mailman/listinfo/toasters