The cpu load of running wafl scan reallocate is very low, and unnoticed on the filers I've run it on. So any fears you had about running wafl commands, I hope that eases them.
--Blake
On 2/21/06, Glenn Walker ggwalker@mindspring.com wrote:
I agree with Herbert's comments that it works exceptionally well in 7.x!
Be warned, if you reallocate the source, the SM updates are going to be large and take a long time (potentially, depending on how much data is shifted around).
As for measure_layout: it has always been my experience that this is something good to look at, but not the rosetta stone for fragmentation... it is an average of all the blocks on the volume and how fragmented they are. What I've always looked at to determine fragmentation is statit output (from perfstat) as it drills down a bit more to what the disks are actually doing. That by itself is also sometimes misleading, however... I'm sure NetApp support will review both to come up with a more accurate prediction.
Glenn
-----Original Message----- From: owner-toasters@mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Herbert Langenbach Sent: Tuesday, February 21, 2006 4:26 AM To: philip.boyle@eircom.net; toasters@mathworks.com Subject: RE: wafl scan reallocate
Philip,
a wafl scan reallocate is just a defragmentation. Did NetApp ask you to run a wafl scan measure_layout? What was the result? BTW, I do not remember any improvement with reallocate in ONTAP 6.x It moves blocks around and comes back with pretty much the same fragmentation as it was before. It really works in 7.x
However, to rule out fragmentation you need the measure_layout value.
Herbert
-----Original Message----- From: Philip Boyle [mailto:philip.boyle@eircom.net] Sent: Tuesday, February 21, 2006 9:06 AM To: toasters@mathworks.com Subject: wafl scan reallocate
Hi guys,
I am seeing increased cpu on a filer. It appears to jump when the filer kicks off a number of snapmirrors. I've updated the threshold so that the mirroring runs a little more frequent and this appears to have reduced the high cpu issue. Note, I'm only running approximately 4 snap mirror threads on a clustered environment so I'm not hitting any mirroring thread limitations.
This increase in cpu is unexpected as the filer is running around 50% less snapmirror threads and 40% less volumes from 6 months ago. so if anything I should see a drop in cpu activity.
Support are advising me to run a 'wafl scan reallocate' as one volume is close to 80% full. I'm not convinced and reluctant to kick off wafl commands.
For your information, I'm running 6.5.3P4 on a 940C cluster.
Has anyone else had similar issues or have ran 'wafl scan reallocate'. Any recommendations for debugging?
I've passed on the relevant 'sysstat' data for a 24hr period to Netapp Support.
Regards, Philip
--