Dealing with Defrag

Monday, October 31 2005 @ 10:01 AM EST

For most of you, defragmentation has become a regular practice in the administration of your Xsan volume. At some point, either capture files, or more commonly, render files are becoming so fragmented across the breadth of the storage that their playback predictably yields dropped frames.

The solution, of course, is to run the snfsdefrag utilitity, found in /Library/Filesystems/Xsan/bin, or to use the handy Xsanity Defrag program, Xsanity's cocoa wrapper of the same utility, in order to address the issue. [Ed. Note: Our Xsanity Defrag is getting old and creaky, and we do not currently recommend it!]

The snfsdefrag utility, used in its simplest form, gathers all the fragments of a given file (called “extents” by the utility) and places them in a section of the free space of the storage in one continuous chunk. The “virgin” territory that it usually seeks out in order to do this is the “far end” of the storage pool, which would usually not fill up until the storage pool itself reached its maximum capacity.

Using the utility on files that otherwise would not playback reliably is a fix that obviously needs to happen in order to deliver a tape, or have a client viewing of a sequence go without a hitch. So, the short-term benefit is impactful and necessary.

However, what has started to become clear is that, after a volume lifespan of just a few months and beyond, fragmentation on a volume that has had a fair share of snfsdefrag sessions seems to go up exponentially. This is caused by a simple and powerful phenomenon: as the fragmented files are transported to the new area of the storage pool, the fragmented areas they leave behind are tagged as free space. When a new file is written to the storage, these “pockmarked” areas of free space are used first, and as we use snfsdefrag more and more, it means that there are more and more tiny areas of free space that are used for new files. Therefore, the possibility of having unplayable fragmented files increases exponentially. Even entire volume defrags leave the “shadows” of these areas of free space, and new captures and renders seem to be written into the same fragments as the did the previous files.

We have reported here at Xsanity that free space pockmarking was a result of not isolating file system metadata to its own storage pool, which is still true. Unfortunately, the phenomenon of using snfsdefrag on the volume contributes a unique, although similar, issue of fragmented free space.

What we need with Xsan is an optimization function, which would essentially reassemble all of these pieces of fragmented free space back into continuous free space, so that new files could be written as single chunks as much as possible.

For those of you who go back on the Mac OS to the time when Norton Utilities was a staple of your administration toolkit, you’ll recall that the SpeedDisk program did exactly what we need for Xsan: it would de-fragment files, but as an additional step, it would also optimize free space as well.

Until Apple addresses this issue by creating an optimization function within the utility, or creating a separate optimization binary, we need to use the snfsdefrag utility as sparingly as possible, in order to prevent premature over-fragmentation of the storage free space.

Here are some tips for using snfsdefrag appropriately…

• Make sure to use the utility in as focused a manner as possible. Don’t defrag the entire volume ever. Try to isolate the playback issues just to the files that are troublesome. Oftentimes, you’ll find that render files are the true culprit. If this is the case, isolate the defrag to just the file, files, or folder that the files are located. If you must defrag an entire folder, be sure to use the –r “recursive” switch on the path of that folder, like this:
  
  sudo snfsdefrag -r /Volumes/MyXsanVolume/Media/Aarons_stuff/RenderFiles/folderthathasfragmentedfiles
• Use the utility verbosely in order to keep tabs on what is happening. Simply place the –v “verbose” switch in the command line to turn on verbose mode. Yes, a lot is going to be told to you, but it is helpful to see the utility feedback its progress. It’s especially helpful to see how long it takes to defragment a particularly fragmented or large file. If we took the previous command as an example, it would turn into:
  
  sudo snfsdefrag -v -r /Volumes/MyXsanVolume/Media/Scotts_stuff/RenderFiles/folderthathasfragmentedfiles
• Become a file fragmentation sleuth. Use the –c “count” switch to not perform an actual defrag, but a simple extent count. This way you can see which files are the culprits by the amount of extents they have. We have commonly seen files that have hundreds and sometimes over a thousand extents. Again, using the above example, if we wanted to simply get an extent count on a folder, we would use:
  
  sudo snfsdefrag -c -r /Volumes/MyXsanVolume/Media/Torreys_stuff/RenderFiles/folderthathasfragmentedfiles
• Use the fragment limiter on snfsdefrag. Have the program skip files that have a small number of extents by using the –m “more” switch in the command line. For example, using
  
  sudo snfsdefrag -v -r -m 10 /Volumes/MyXsanVolume/Media/Adams_stuff/RenderFiles/thisproject
  
  within the command will have the utility skip any file that has 10 extents or less. This really speeds up the process by skipping files that probably don’t need defragging.
• If possible, “relocate” the file to a new or less-used storage pool. The utility can be used creatively to copy the new file to another storage pool using the storage pool’s affinity. This can be done by using the “more” switch, mentioned above, in combination with the –k “key” switch to specify an affinity. We can force the file to be moved, fragmented or not, by using “–m 0” within the command. We can then relocate it to a new storage pool by specifying “-k ”. For example:
  
  sudo snfsdefrag -k newmedia -m 0 /Volumes/MyXsanVolume/Media/Bonnies_stuff/RenderFiles/thatproject/reallyfragmentedfile
  
  This will force the file “reallyfragmentedfile” into the storage pool that bears the “newmedia” affinity, and in one extent as well. Remember, affinity names usually differ from their storage pool names, since they can only be eight alphanumeric characters in length. Check your .cfg file in the mdc’s /Library/Filesystems/Xsan/config folder to see what affinity name each of your storage pool’s have.
• Avoid using the –p “prune” switch. This switch frees up pre-allocated blocks from files that ended up not using them, but this means these blocks will be fragmented as well. Therefore, using this switch, even though it does sometimes free up a significant amount of space, fragments the storage even further
• If you’re trying to defrag files from an active FCP sequence, you must close that sequence, or open another. If you’re running FCP at the same time (on any machine connected to the Xsan) that has an active sequence containing the fragmented files, the utility will skip these files because they are being used by FCP. Also, snfsdefrag will not operate on files that were saved 10 seconds ago or less.
• Don’t launch the utility on more than one machine or in multiple sessions. This would seem obvious, but snfsdefrag can accidentally be run in multiple sessions, whether from the same machine or difference machines. When this happens, the utility tries to defragment files that the other instances are in the process of defragmenting. The result is files that remain accessible on the file system, but are unopenable.
• If your defrag is taking too long, it’s ok to press Ctrl-Z. The last file that was being fragmented will finish, and the utility will exit gracefully. If you accidentally kill the utility or there’s a power failure during the session, you will find a “__defragtemp” file somewhere on the storage. Simply delete that file to reclaim the space that was temporarily being used to defrag this file.
• Lastly, report your successes and horror stories here on Xsanity. This way we all figure this out together.

0 comments

http://www.xsanity.com/article.php?story=20051031100153656