Gallery cannot provide technical support for your Apple XSan problems. However we have listed some of the most common issues below (as reported to us by 3rd parties) in case this helps you. If not, then please visit our 'Where to now ?' page to find XSan technical support.

To check that the problem is related to storage, try capture/playback etc using your internal local hard drives instead of the XSan.

Most XSan issues seem to revolve around dropped frames, or aborted recordings, or corrupt files. Please check the following:

1) In some older versions of XSan, A Dual fibre connection between the card and the switch is not reliable in some cases. Remove one of the fibre connections. This may help with aborted recordings, or file corruption. This problem should not affect current versions of XSan. Contact Apple for further information on this issue.

2) If you use QLogic switches, you need to ENABLE I/O Streamguard and DISABLE device scan on specific ports. This should help with dropped frames, especially ones that correspond with a reboot of another CPU on the fibre. Contact Apple or QLogic for further information on this issue.

3) The configuration in which the XSan is initialised can make a huge difference to the performance and reliability in specific operations. Try reconfiguring and reinitialising your XSan according to Apple documentation and guidelines. Contact Apple for further information on this issue.

4) Make sure you have plenty of RAM in your RAID subsystems and your XSan metadata controllers.
Contact Apple for further information on this issue.

5) Make sure that Host Cache Flushing is turned OFF on your Raid subsystems, otherwise you may periodically drop frames. Contact Apple for further information on this issue. Here is a screenshot showing the recommended settings, from an Apple Engineer

More Advice from an Apple XSan Engineer

Important information on 4GB Fibre
http://docs.info.apple.com/article.html?artnum=307386

Qlogic Switch Configuration
Review the Streamguard settings on the target/initiator ports. Enabled for initiators (host); disabled for targets (storage). Some also disable the 'Device Scan' on initiator ports.

Qlogic provides an excellent PDF regarding their switches & Xserve RAID & Xsan (google search for "SN0054606-00D") Page 125 discusses the issue:

I/O Stream Guard is a QLogic feature that addresses the problem of guaranteeing uninterrupted data flow,
specifically in sequential data applications such as streaming media for video/audio and backup of
centralized storage. Continuous sequential data flow is impacted by an event called a Registered State
Change Notification (RSCN) when it comes from a device other than a storage target. I/O Stream Guard is
used to intelligently manage interruptions caused by RSCNs.

I/O Stream Guard was developed by QLogic to assist the video markets requirement for uninterrupted
sequential data flow. It works by intercepting RSCNs generated by initiators (servers) on I/O Stream Guard
enabled ports and stops them from being transmitted to other I/O Stream Guard enabled ports. When it is
important for RSCNs to get through to the device—for example, with a zoning change or the addition of a
new target device to the fabric—I/O Stream Guard allows these RSCNs to go through.

Xserve RAID Settings
Check that all Xserve RADIs have "Host Cache Flushing" disabled – or unchecked. After power failure or shutdown, the Xserve RAID controllers reset their advanced performance settings to ensure data integrity. For high throughput deployments we enable both drive & controller caches; although, these systems should have both conditioned & UPS power lines.

Core Network Settings
Verify that your metadata network settings are correct (IP, subnetmask, no router) , and you have a clean & private (no additional traffic) metadata network. If necessary, you can test the network performance. Search for darwin port of bin netperf and generate a test of TCP response rates via terminal. Running on the client, run "sudo netserver (or path to whereever you downloaded the bin file)", and then run netperf -t TCP_RR. You want to achieve a rate above 15,000; otherwise, your metadata network will create performance issues.

Apple's Xsan Performance Article
http://docs.info.apple.com/article.html?artnum=301740

If none of this has resolved your XSan problem, please visit our 'Where to now ?' page to find XSan technical support.