BTW, I just did this in two of the 8080 nodes in our 8-node C.DOT running 8.3P1D4:
$ seki1 'set -priv diag -conf off; run seki1-07 "options wafl.deswizzle.enable on"' $ seki1 'set -priv diag -conf off; run seki1-08 "options wafl.deswizzle.enable on"'
These have 7.2K rpm drives only -- kind of a Tier 2 if you like, for primary NFS workload mainly. I got curious to see what happens with the NFSv3 latency seen by the clients when all the deswizzling starts :-)
The NFSops/s load point is really low here now, the working day is over local time is 18:19. So the first thing i see in the protocol latency is that the metadata (GETATTR + ACCESS + LOOKUP ~= 80% of our ops) jumped up from sub 100 us sustained to 2-400 us. No big deal that, so... I shall dig around to look at some other Perf Counters to watch the effect better
Anyway, these lightly loaded 8080s now show this (auto tuned):
$ xxxx1 'set -priv diag -conf off; run xxxx1-07 "wafl scan speed"'
WAFL scan speed is 31800
$ xxxx1 'set -priv diag -conf off; run xxxx1-08 "wafl scan speed"'
WAFL scan speed is 30300
If the tuner thinks things are getting bogged down, it turns this down to 1300, that's the lowest it'll ever get as far as I know and have ever seen
/M
I wrote:
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