The command cvfsck (in the folder /Library/Filesystems/Xsan/bin/) can be very useful to both diagnose and repair filesystem-level problems on your SAN. Not well known is the fact that the command's parameters change from one Xsan version to the next.

Apple has created a handy guide to using cvfsck for the different Xsan versions in circulation. It's worth double-checking this knowledge base article before running your SAN aground.

The general rule with Xsan, since version 1.1 or so, is this: DNS isn't necessary, but if you have some you had better make sure it is perfect. A few of us are beginning to suspect that DNS is, in fact, required, although in a very obscure way. It will take me several paragraphs to explain why, but let me get to the bottom line first:

Your DNS servers should include a zone for reverse lookups of your metadata (private) IP range. Ask your DNS administrator to create a reverse zone for this range, with SOA and NS records. PTR records aren't needed.

Read more to find out why.

[Ed. Note:]On Friday, September 8, Apple vaguely reported security problems with ACLs if Windows clients are currently or were formerly part of the SAN. See Security "issues" with Windows clients & Xsan 1.4 for more information.

Xsan 1.4 is finally out, and the new version brings with it some improvements a lot of us have been waiting for. Perhaps the biggest news is support for LUNs over 2 terabytes, so you can use the entire capacity of a fully populated Xserve RAID without taking a performance hit. The updated Xsan should also facilitate adding storage to an existing volume and boost performance for volumes that are shared out over network protocols like AFP and SMB. (Update details at Apple's download page)

One less obvious improvement will benefit Xsan’s IT datacenter and media production customers alike, and this is support for filesystem-level access control lists, or ACLs.

The most mystifying component of our SANs has got to be the fibre channel network. With heavy black boxes, bright orange cables, even lasers, it sends our PKE meter off the scale. Even the management software manages to either look like a Windows program or require -- ack -- Internet Explorer!

This article may help shed just a little light on your fabric. The idea is to set up zones -- lots of zones -- to make your SAN behave more predictably. It can be a lot of work at the beginning, but you get several important benefits.

• Broadcast traffic is isolated between clients, minimizing client-to-client conflicts
• New devices are effectively invisible until deliberately added to a zone

Apple quietly slipped this article into the support library at the beginning of the month. When I ran across it Thursday, I gave it a quick mention in our forums, not too much fanfare in case I was the only one late to the party. But the response we've gotten online and off since suggests that maybe this merits a headline -- the article certainly explains at least one SAN expansion problem we've seen first hand.

In short, if you want prime-time stability working with LUNs greater than 2TB, you need to fire up Terminal and label the LUNs manually, specifying a custom sector count size that will work better than the one Xsan Admin configures. The instructions are pretty hardcore command-line stuff, not for the faint of heart, but it's nice to know you don't have to wait for Xsan Admin 1.3 to get it right.

[Ed. Note: Our comments indicate a lot of confusion about this post. Xsan 1.2 and earlier are still limited to 2 TB per LUN. Larger LUNs must be truncated. The news is that Xsan Admin, a GUI for stuff you can do on the command line, does not truncate correctly. Storage Pools lose their elasticity, and cannot be expanded in the future. So use Apple's command-line procedure to truncate the LUNs properly. (Our forums have a better explanation.)]

Sometimes a drive fails, or a RAID controller goes down on an array with a redundant drive and the parity on a RAID must be rebuilt. In other words, if you loose a drive in a RAID 5, RAID 1, RAID 0+1 or RAID 3 array you will be left with a degraded RAID (also referred to as a critical RAID) unless you have configured your Xserve RAID to use a hot spare. If you are using a hot spare on the channel of the failed drive the RAID will begin to rebuild itself automatically. If you are not using a hot spare, upgrading your degraded RAID back to a healthy state should happen as quickly as possible to avoid data loss. In the event of a second drive failure on the array most of the data could be lost -- and Murphy’s Law is evil when it comes to RAIDs. The data should be backed up as quickly as possible if it has not already been backed up.

In many situations you will be able to simply swap the bad drive out with an identical good drive and configure it as a hot spare. Then the Xserve RAID will automatically begin rebuilding the array, moving it from a degraded state into a healthy state.

However, there are often logical issues with drives and arrays. Also, hot spares do not always join the degraded array. In these situations you may need to manually rebuild an array. The instructions are below.

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.