Since Xsan 1.3 was released, we've received several reports of bugs: Photoshop files becoming corrupted, gray boxes on renders, and kernel panics on captures.

Now our buddy MattG, who reported many of the initial problems, is seeing better results with the combination of Xsan 1.3 and Mac OS X 10.4.7. At least the Photoshop corruption issues seems to have been addressed in the 10.4.7 update.

Xsanity is asking all Xsan 1.3 users to read Matt's post and contribute additional experiences. Thanks!

ManageEngine OpStor is software for storage infrastructure monitoring. You have an overview about events, receive alarm messages, performance, reporting and much more. At the moment, Xsan is not directly supported; but for switches and HBAs it's very interesting. (Note I'm NOT working for this company; but we'll use this software in the future for our Xsan; qlogic - switches.)

[Ed. Note: this is software that runs on Windows or Linux.]

ADIC has released their release notes for StorNext 2.7 on their documentation server. Since StorNext and Xsan share some of the same code base, you may find these notes helpful.

Here are a couple of geeky nuggets unearthed from the notes:

• Modification times should be more accurate
• Reserved extents is now reported towards used space, allowing more efficient use of nearly-full volumes.
• There is a discussion of "trespassing files," which extend past the 2GB limit on older LUNs.

Note there's a very tempting mention of a backup system included in StorNext. As far as I can tell, that's just for the Management Suite, and usually won't apply to Xsan. Sorry.

Do Apple's release notes leave you hungry? Use ADIC's StorNext documentation server. Sharing much of the same code, Xsan and the StorNext File System also frequently share the same limitations and bugs. ADIC is simply more forthcoming in their documentation.

For example, Apple's release notes for Xsan 1.2 on 10.4 compact the changes into nine bullet points. ADIC's release notes for SNMS 2.6.1 fill 30 pages.

Note that ADIC's notes lump together the StorNext File System with the Management Suite. The Management Suite is a much bigger beast than Xsan, and many of those 30 pages won't be relevant to a mostly-Xsan installation. Even so, you may find ADIC's forthright elaboration of Resolved Issues and Limitations very helpful.

Data transfer speed to and from Xsan volumes depends mainly on the following factors:

1. Ethernet network configuration and load
2. Fibre Channel network layout and configuration
3. Xserve RAID configuration
4. Volume and storage pool configurations
5. Xsan File System configuration

[Ed. note: David has done a great job extracting and summarizing the information in Apple's Xsan Tuning Guide]

Our colleagues at afp548.com posted an examination of RAID Admin 1.5, detailing new features like Enhanced JBOD (not good for Xsan), Steady Streaming (also not for Xsan), and Enable Host Cache Flush (disable for Xsan). Worth the read.

UPDATE: The premonition about fragmentation was correct. The morning after the pruning was filled with dropped frames. Be careful using this operation on volumes used for video storage.

When you write files to an Xsan volume, an application can ask the metadata controller to preallocate a certain number of blocks on the filesystem. But you may not end up using all those blocks for data. To quickly recover that allocated, but unused, space, type this command:

sudo snfsdefrag -rvp /Volumes/XSAN

Instead of "XSAN" type the name of your Xsan volume. On one 14 TB volume that was a bit less than half full, I recovered 700 GB. (Of course, that space is going to be pretty fragmented.)