In the life of an Xsan shop, you will at one point or another be presented with the need to defragment your volume. Defragmenting a volume is a good way to recover lost performance, but can also be beneficial in other scenarios: defragging is an absolute must after performing a bandwidth-style expansion of your volume, and is often recommended (though not absolutely necessary) when performing a capacity-style expansion. In case you’re confused, a bandwidth expansion is the type of expansion performed when you add LUNs to a specific storage pool. Conversely, a capacity expansion involves simply adding new storage pools to an existing volume.
Because the make-up of a storage pool is drastically altered when a bandwidth expansion is performed, the data is not properly distributed across any of the new LUNs that were added to the pool, this results in a shadow-effect where all capacity of the storage pool is not available for use by the system. Because of this, it is an absolute requirement that a defrag routine is ran. To perform this defrag, we use the standard snfsdefrag command, but we use the special ‘-d’ flag, which ensures that this shadowed storage space is reclaimed and that data is properly distributed across the storage pool:
snfsdefrag -dr /Volumes/MyXsanVolume
There are several scenarios where it may be desirable to rebalance the data on an existing volume. A capacity expansion of a volume will result in one or more new storage pools being added to the volume, but the new storage will not have any data written to it. Alternatively, an allocation strategy of round-robin or fill can, over time, result in a poor distribution of data across your storage. By spreading data across the storage evenly, you ensure that all disks are running at similar capacities, therefore netting more consistent performance across the volume, as disk performance tends to degrade as capacity increases.
When an snfsdefrag is ran, it will defragment files as specified by your parameters, and these files will be distributed onto the volume as per your allocation strategy. If you defragment a volume that has a ‘Fill’ allocation strategy, you will not gain any benefits of having evenly distributed data, though your individual files will no longer be fragmented.
Thus, if your main goal is balance all data across the volume, it will be necessary to change the volume’s allocation strategy to Balance and then defragment the volume. This will result in fragmented files to be relocated the lowest-capacity pool, an extremely effective method for balancing data. In Xsan 2.x, you can change a volume’s allocation strategy at the GUI level, which can be changed while the volume is live. In our experience, the change can be performed live and will not result in Xsan client service interruption to the volume, and active transfers proceed with no disruption. Even so, it’s best to perform the switch at a time when there’s minimal activity (preferably none) on the volume and no active transfers in progress.
Once you’ve converted the volume to the new strategy, you can proceed with the optimization, which is a fairly straightforward defrag performed with the command
snfsdefrag -r /Volumes/VolumeName
This will defragment any files with more than one extent, re-provisioning the optimized files to the next LUN in the allocation strategy. And because we’re now using the Balance strategy, the next LUN will always be the one with the lowest capacity—-our new LUNs, in this case. If, however, you had a healthy Xsan volume, this command may not properly balance data, because fragmented files will be rare. In such an event, run the command
snfsdefrag -r -m 0 /Volumes/VolumeName
This will defragment files with more than 0 extents, which is every file on the system, letting you rest assured that the volume will be nicely balanced at the end of the operation. The main trade off here is that doing so re-provisions all files on the volume, which can be a very time consuming task. If the volume has standard levels of fragmentation, running the command without the flag should do a decent job of balancing without having to operate against non-fragmented files as well.