I think it's general knowledge that once a NetApp gets above 90% full, performance starts to degrade quite noticeably.

This happens because free disk blocks become scarce. WAFL tries to use free blocks in the same raid stripe to reduce updates to the parity disk. When free blocks are scarce they are scattered over different raid stripes so more parity updates are required. And if WAFL has to use free blocks from different cylinders, then this causes more disk head movement.

I've been testing an application recently and observed that this is the case on ONTAP 5.2:

• When ~95% full, my performance test came up with a number of ~4

seconds.

• Freeing up space to get to around 60% full, the number was ~3.5

seconds.

• Copying off my data files and copying them back to defragment them,

the number was 2.8s.

The only thing I've been able to find about fragmentation is:

• Some statements that WAFL tries hard to avoid fragmentation (which

I'm sure it does) but can't always (which I'm sure of too).

• Copying off data and copying it back again is the only way to

resolve it.

The latter solution doesn't seem practical if the data in question is supposed to be available 24*7. Some applications have a method of doing this at an application level, but does anyone know whether there are methods/future plans for background non-intrusive defragmentation at a filesystem level? Or is it just me who thinks this would be a good idea?

If speed is more important than space, then you will have better performance if you don't let the volume fill up. When WAFL has plenty of free disk blocks to choose from, it can write the data efficiently and this means that it can read the data back efficiently, too. (Data written inefficiently is also inefficient to read.)

You should also try to avoid creating a "hot" disk. This happens when you let a volume fill and enlarge it with one new disk. Now all your free space is on the new disk, so WAFL cannot spread writes out over all the disks in the volume.

If you enlarge a volume this way and create a "hot" disk, you can alleviate the situation. Look for old, seldom used files that were written when the volume was new and had plenty of free disk space. Make copies in the same volume of as many of these old files as you can. These copies will be written inefficiently on the new "hot" disk. Remove all your snapshots. Remove the original files and rename the copies to the original names. This frees up disk space that is scattered over all your disks, making the "hot" disk less of a problem.

If a volume has a high "churn rate" (i.e., rate at which most data in the volume gets replaced) then a "hot" disk will eventually disappear naturally. When old files are deleted it frees blocks on multiple disks, which tends to even out the distribution of free space.

Steve Losen scl@virginia.edu phone: 434-924-0640

University of Virginia ITC Unix Support