Fragmentation is basically the result of files being broken up in to smaller parts and stored wherever there is available free space on the disk, and reading a fragmented file will be slower as all the parts have to be accessed at the various physical locations on the disk. For an Xsan the files can be very large and severely fragmented over several disk arrays.

OS X has some mechanisms to try to avoid file fragmentation, but these apply to the HFS+ filesystem and are of no use with an Xsan Volume.

Apple says there are two scenarios under which you might need to defragment your drive; there are many large files (such as digital video) and the disk is low on space - typically more than 90% full. Their information on disk defragmentation is not too helpful as their Knowledge Base article [PH5862] says "you don't need to defragment or optimize your disk when you use Mac OS X," and then tells you it probably needs to be 'repaired'. There are also a few KB articles for when using Xsan [TS2778, TS2741] that tell you 'frame dropping' may be due to a Volume becoming fragmented and provides instructions for what you should do to remedy it.

Defragmentation may have to be performed on an Xsan Volume for two main reasons:

  • Normal usage filling the available space and file manipulation causing fragmentation.
  • Performing a bandwidth or capacity expansion, and data redistribution to improve efficiency.

Xsan Maintenance for Normal Usage

In maintaining or troubleshooting an Xsan Volume, many users find that file fragmentation does not become an issue until the filesystem reaches around 75% full, and individual files may exhibit poor read performance when their extent count – number of segments – reaches around 5000 to 10000. Check the size of the file that is exhibiting dropped frames; a large file with many extents will cause a busy system to work harder to retrieve all of the file segments.

Many users say that when the filesystem becomes too full and the files too fragmented, copying all the data on the Volume to another location, recreating the filesystem, and using the Xsan 'cvcp' command to copy the data back to the filesystem, remains the best option, but there are the actual Xsan maintenance tools to consider.

Fragmentation

Fragmentation can become a major problem on an Xsan Volume, and the number of extents at which read issues can occur can vary by the file, resulting in dropped frames to clients.
Performing defragmentation on an Xsan Volume can affect the performance of attached clients so it is definitely best to do it during a quiet period such as overnight.

To defragment an Xsan Volume use the 'snfsdefrag' command:

# sudo snfsdefrag –r -v [-m X] /Volumes/

You can specify that only specific directories be defragmented, which is useful if you are using affinities.

The –r option tells it to move recursively through the named directory.

This task can be performed with the Volume on-line and in use but be aware that performance can be slower as a result.

You can speed up the defragmentation process by using the –m option to specify the number of extents a file must have to be defragmented.

The –c option is useful to display the extent count – without performing a defragmentation; you could set the value for the –m option based on the results. 

The –l option will return a list of files that could use defragmentation.

Pruning

When Xsan writes a file to the volume it pre-allocates the amount of storage that it thinks it will need to write that file, which is beneficial as it reduces fragmentation under certain circumstances, but if the file does not consume the reserved blocks they will remain allocated. Usually this is one or two blocks per file, but can certainly be more than that if a file has shrunk in size.

Pruning is the process of looking for and freeing those allocated blocks, and it can free up from several kilobytes to several hundred gigabytes.

To prune an Xsan Volume just add the “-p” argument to the 'snfsdefrag' command:# sudo snfsdefrag -rpv /Volumes/[VolumeName]Filesystem Check

# sudo snfsdefrag –rpv /Volumes/[VolumeName]

Filesystem Check

Proper Xsan Volume maintenance is critical to the health of the filesystem, and many Xsan administrators try to run a filesystem check on each Xsan Volume at least once a month - and not just when there are problems.

First stop the Volume:

cvadmin
# stop [VolumeName]
# exit

Next, perform the file system checks on the journal, followed by a read-only and a read/write scan:

cvfsck -jv
cvfsck -nv
cvfsck -wv

When these have completed you can re-start the Volume:

cvadmin
# start [VolumeName]
# exit

Note the time that the “cvfsck” will take depends on how much data is on the Volume.

If the “cvfsck” scan indicates that the Volume is “dirty” instead of “clean” then ensure the Volume is stopped.Then run the "cvfsck -wv" command again for a "clean" result.


Xsan Maintenance for Volume Expansion

There are two types of expansion possible:

  • Bandwidth expansion, where one or more LUNs are added to a Storage Pool.
  • Capacity expansion, where one or more Storage Pools are added to a Volume.

Bandwidth Expansion

When performing a bandwidth expansion, one or more new LUNs are added to a Storage Pool, which will result in the structure being significantly altered. Data that was written to the Pool earlier will have been distributed across the original set of LUNs, and now with additional LUNs available the data will be distributed across the original and new LUNs.

The result is that there could be an area of shadow space that will not be usable by the Xsan.
That is why it is necessary to defragment the Volume after a bandwidth expansion using the –d option; it will re-distribute the data across all of the LUNs in the Pool, effectively reclaiming that shadow space.

# sudo snfsdefrag –d –r /Volumes/[VolumeName]

Capacity Expansion

When performing a capacity expansion of a volume, one or more Storage Pools are added to the Volume, but the way in which the data is distributed over the Pools depends on the allocation strategy selected. 

The three types are:

  • round robin: new data will be written to all Pools in the Volume.
  • fill: data will be written to the first Pool until it is full, then move to the next Pool.
  • balance: data will be written to the Pool with the most free space.

Round Robin can pose a similar problem as in bandwidth expansion as the new Pool(s) may have data written to it but it could have significantly less than the first Pool(s) did. Defragmenting the Volume will result in files being moved to areas with more free space regardless of the distribution of the data over the Pools.

Fill can have a similar effect as well with the new Pool(s) being under utilized until the first Pool(s) are filled. Defragmentation will result in the data being evenly distributed across the Pools, but that is it.

Balance tries to keep files contiguous by using the Pool with the largest free space, so defragmentation will relocate defragmented files to the Pool with the lowest used capacity – the new Pool(s). This provides the best performance for a Volume that has more than one Pool.
Note that if your Volume does not have many fragmented files there will be no changes to the file locations, so you will have to force the process to work on every file in the Volume by telling it to defragment files with “0” extents – basically all files – by using the “–m 0” option. This can take a long time to complete, so your fragmentation level should be considered carefully before doing this.

You can change the allocation strategy of your volume from the Xsan Administrator GUI at any time with no disruption to service, but this is best left to down time such as over night. 

After making any changes you have to defragment the Volume:

# sudo snfsdefrag –r /Volumes/[VolumeName]