I'll weigh in on this, though by now the question is probably moot, but before I do so, I'd like to say fragmentation isnt neccesarily a bad thing, fragmenting one chunk of data and storing it on multiple spindles can actually improve performance. Fragmentation on a single drive (whcih is what most of us suffer from), is almost universally bad. WAFL has something which is analagous which is a combination of having fewer good areas to write full stripes and increased metadata loads which happens over time until it reaches a steady state. A better term for this is "dataset ageing". Having said that let me answer the question as best as I can.
1. The performance of backup to disk targets on NTFS filesystems degrades over time, in many cases the degradation of performance is significant. The more full the NTFS filesystem is, the faster this happens, from long experience NTFS really needs at least 20% of the available space to remain free in order to retain high performance. This happens regardless of the underlying storage platform. I've seen this happen on DAS, EMC CX, EMC Symmetrix, HP-EVA, and FAS.
2. This performance degradation may be more pronounced on an OnTAP based system, especially if the aggregate which hosts the LUN has less than 20 or so spindles (rule of thumb). In an aggregate with more than 20 spindles (or two shelves in the old DS14 days), the additional spindles, and optimisations available through advanced readahead algorithms and readsets will generally allow OnTAP based systems to exceed the performance of most other storage architectures.
3. For more typical NTFS workloads, the way WAFL reorganises random writes into sequential writes actually offesets the effects of NTFS fragmentation. In general data is requested in the same temporal patterns that it was written in. For example a database record and its associated index are likely to be written to two quite different physical locations/LUNs, however as they are written at the same time, WAFL will write these close together on disk (hence maintianing temporal rather than spacial locality of reference). Typically when the index is read the database record will also be read, rather than issue two seperate read requests for this data, the entire set is predictively gathered in a single sequential read operation. WAFL also effectively cancels out NTFS's nasty habit of fragmenting free space by ignoring the extra whitespace that NTFS adds to the end of every file.
4.I personally am a big fan of "Write After Read" reallocation for many workloads. This has been available as a volume option since 7.3.1 and is a lightweight way of reducing the impact of WAFL ageing, especially for NAS workloads.
5. For some other workloads (Exchange comes to mind), regular nightly reallocation scans are an excellent idea, especially for systems with aggregates containing less than 20 spindles. I've even seen reccomendations similar to the following.
"In the absence of specific problems or detailed knowledge of the application, all volumes containing SAN data (that is, LUNs rather than files), and all volumes containing database tables hosted on NFS, should be set up with a default, once a day, check and conditional reallocate process. The reallocate command should be run on other volumes only when the administrator has specific application knowledge suggesting that there will be a performance benefit."
6. Ever since 7.3.1 (maybe 7.3.0), there has been a -p option available which removes the old limitations of reallocate that used to cause snapshots and snapmirror updates to blow out. THere are some limits to which volumes can do this (IIRC the -p option works with volumes created in OnTAP 7.2 and above). In the past the snapshot/snapmirror blowout probably made netapp a little wary of recommending wholesale use of reallocate, however now that 7.3 has been a GD release for quite some time and has a large install base, my personal feeling is that we should be more proactive in our reccomendations.
7. Always remember that your mileage may vary, and that you should always excercise "Rule 0" - use good judgement. If youre worried about your current performance, and are concerned about the potential implications of running reallocate for your production system, collect a perfstat and raise a call with the Global support center, they should be able to tell you whether reallocate is a good option for you.
