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(a)mathworks.com [mailto:owner-toasters@mathworks.com]
On Behalf Of Herbert Langenbach
Sent: Tuesday, February 21, 2006 4:26 AM
To: philip.boyle(a)eircom.net; toasters(a)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(a)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
--