There are significant differences between 'wafl-scan-reallocate', 'reallocate' and 'reallocate -f'.

o wafl-scan-reallocate reallocates if it thinks data layout is improved, and is controlled by wafl-scan-speed.

o reallocate reallocates if it thinks data layout is improved, and typically moves less data than wafl-scan-reallocate (it looks for short contiguous sections and leaves them alone for example). The speed is automatically adjusted based on system load, which has been tuned from 7.0 through 7.2

o reallocate -f reallocates unless it thinks the new layout would be worse. This is handy for cases like adding a RAID group to an aggregate that is not fragmented. The speed is automatically adjusted based on system load as above.

In 7.1 onwards the automatic system speed adjustment can also be overridden with wafl-scan-speed if desired.

-----Original Message----- From: Philip Boyle [mailto:philip.boyle@eircom.net] Sent: Wednesday, April 11, 2007 6:18 AM To: Blake Golliher Cc: toasters@mathworks.com Subject: Re: reallocate experience?

Thanks for the quick reply Blake.

My understanding is that by default, reallocate will not change anything. unless it is perceived to optimize the volume layout.

The filer isn't particularly stressed at present so I don't envisage any major performance impact:

$filer> sysstat -u -c 5 5 CPU Total Net kB/s Disk kB/s Tape kB/s Cache Cache CP CP Disk ops/s in out read write read write age hit time ty util 8% 1106 302 593 2151 2348 0 0 27 98% 20% T 13% 5% 1057 1259 439 319 204 0 0 27 98% 2% : 2% 4% 809 263 586 799 6 0 0 27 97% 0% - 4% 8% 1117 538 665 2703 3194 0 0 27 98% 25% T 15% 4% 898 290 770 773 11 0 0 27 97% 0% - 3%

I'll hold the reallocate option in reserve if my results from 'statit' and 'sysstat' aren't up to speed.

Regards, Philip

Blake Golliher wrote:

Reallocate can take a long time. You can increase the wafl scan speed

which controls how much data is read and processed, but that can start

to effect performance. I've not seen it effect performance to terribly, with out modifying the wafl scan speed. Naturally on workloads that are more disk intensive your milage may vary. 7 offers

the ability to schedule regular reallocates to help with hot disk issues. Keep in mind new data will be written to the new disks, so as

long as you add disks in groups, you shouldn't have too poor an effect

on performance.

-Blake

On 4/11/07, Philip Boyle philip.boyle@eircom.net wrote:

...

Hi guys,

Has anyone seen any issues with using the reallocate command in relation to a) increase in snap shot usage b) performance impact c) length of time to run the reallocation?

I may have a requirement to reduce the raid group size option( currently 28 ) on an existing 12 disk aggregate to 16 and add additional disks,

...

thus potentially creating the presence of 'hot disks' in the primary raid group which will have been increased from 12 to 16 disks.

http://now.netapp.com/NOW/knowledge/ docs/ontap/rel70rc/html/ontap/cmdref/man1/na_reallocate.1.htm

Any feedback on past experience would be useful.

I'm running ONTAP 7.0.4 on an FAS940 cluster with legacy LRC modules and 36G disks.

Thanks, Philip