On 2016-10-19 17:35, Flores, Paul wrote:

does seem to be running away with the box. Was this box upgraded from an older version of software?

Do you use .snapshot/ for a lot on this box..? I.e. do you read from them, more than like now and then (for occasional restores)?

You can [manually] kill any BG deswizzler scanner whenever you like, it won't do any harm to anything.

BG deswizzling isn't terribly important to run in majority of scenarios. The deswizzler scanner is quite stupid (inefficient), it reads 4K WAFL blocks and it traverses inodes.

If you have dense file data, it takes forever to run, for no benefit basically. Especially in a larger FAS (which this isn't, I know) deswizzling can (should IMO!) simply be turned off. There's a *global* knob that does this, in 7-mode it looks like this:

wafl.deswizzle.enable off

Don't know off the top of my head for cDOT, sorry. N.B. deswizzling will still happen, on the fly, when WAFL blocks are read the first time and there's an extra pointer there which can be taken away.

Anyone who has ever done reallocate start -A -o <aggr_name> on a large Aggr with FlexVols of very high inode density, have been in contact with the BG deswizzler scanners.... they hurt the system, pretty much for nothing. As soon as the blkrealloc phase has finished, and one BG scanner per FlexVol is kicked off *all at once*.

I ALWAYS just kill all of those, pronto. By doing reallocate stop quite simply the minute the blkrealloc phase is finished.

Hope this helps!

/M

*From: *toasters-bounces@teaparty.net on behalf of Edward Rolison ed.rolison@gmail.com *Date: *Wednesday, October 19, 2016 at 3:00 AM *To: *"NGC-chowell-uwf.edu" chowell@uwf.edu *Cc: *"toasters@teaparty.net" toasters@teaparty.net *Subject: *Re: Culprit...

Try 'priv set -q diag; wafl scan status'. You may find it's a deswizzle operation if it's a snap mirror destination.

On 18 October 2016 at 20:13, Carl Howell <chowell@uwf.edu mailto:chowell@uwf.edu> wrote:

I've got an aggregate on a FAS2554c, running ONTAP 9, that runs at over
4500 read IOPS constantly. All of the volumes in the aggregate don't
generate near that many IOPS and SnapMirror doesn't look like the cause
either. I've used OCUM, statistics show...., etc, and haven't been able
to find out what's causing this. Any suggestions?

Thanks,

--Carl