Quantum StorNext is hosting its first Xsan to StorNext Conversion WebEx on October 31 at 11am Pacific. The link is pasted below. There will be valuable information on the benefits of converting to StorNext as well as new special conversion offers.

http://quantum.mv.treehousei.com/Surveys/57/E79541B28D51D0BE/25725_OFT.aspx

It has taken seven years, but Xsan has made the pages of the New York Times. In tech columnist David Pogue's post on Mountain Lion, Xsan got mentioned!

The most relevant section of the press release

"For Mac OS X only-based StorNext File System environments, StorNext 4.3 now supports Named Streams. StorNext 4.3 enables simpler hardware upgrades and disaster recovery. With the ability to migrate file system metadata stored on the metadata controller to a different disk geometry, the software allows customers to take advantage of new drive capacities and technologies."

More after the break....

Since the new Retina MacBook Pro doesn't have room in its chassis for chunky ports like RJ-45, Apple has released a Thunderbolt to Gigabit Ethernet Adapter to compensate. There is also a software update to make it compatible with existing Thunderbolt Macs. Thankfully the Promise SANlink has a Thunderbolt loop-through port, so this allows the Mac mini Server to have more than one Gigabit NIC for MDC service without resorting to an external PCI chassis.

Xsanity will be at the MacTech OS X Server Administration event in NYC next week. Not in New York? With 15 events all around the U.S., there's one coming to your region. MacTech events are one-day conferences aimed at Mac IT professionals.

Get $200 off plus a free subscription to MacTech magazine by registering through this link: http://www.mactech.com/events/locations?rid=Tekserve

Make sure you stop by Tekserve's table for a free gift.

Today Apple posted a short white paper "Final Cut Pro X: Xsan Best Practices."

KB article: http://support.apple.com/kb/HT5084
White paper: http://images.apple.com/finalcutpro/docs/Final_Cut_Pro_X_Xsan_Best_Practices.pdf

Excerpt from the intro:

This document is designed to help you determine the best way of working with a SAN, such as Xsan, to speed up creative work and eliminate copying files across networks or hand-carrying hard drives on multiuser projects.

Two common scenarios are described below.

The first scenario sets up Final Cut Pro X for multiple users who will share a single project and Event, with editing access limited to one user at a time. This is essentially a “check-in/check out” workflow—for example, two editors on day and night shifts, or an offline editor who hands off the rough cut to another editor in a finishing suite.

The second scenario sets up Final Cut Pro X for two workstations sharing the same media simultaneously. For example, one workstation might act as the media-importing station and as a secondary edit station. The other workstation might be used for editing only. In this scenario, both workstations can access and edit the same original imported media stored on the SAN volume.

As far as I can tell, this is just a description of how best to use the Xsan support added in 10.0.1. I don't see that 10.0.2 or 10.0.3 have any special features that are leveraged here.

The Xsan support described is pretty simple and not very different from that of Final Cut Pro 7 and prior versions.

Basically, Final Cut Pro X relies on an Event database that it must have exclusive write access to. It is located in a folder, usually with its related media, and can reside anywhere on the SAN (not just in a root folder) as long as it's not nested within another Event folder.

Solution 1, sharing a single project and Event, is done by using and writing the event and project to a single folder location on Xsan (initiated by the File menu command "Add SAN Location"). When one editor uses the File menu "Remove SAN Location" command, or quits FCP X, the project is closed, and the Event database is released and made available to another editor to open and have exclusive write access to. So there will be just one project file, which can be used by only one editor at a time.

Solution 2, sharing media, is done by each editor having their own event folder (with its own event database) on Xsan. The second editor will point at media in the first editor's folder, but will use the media by reference instead of by copying it to their own event folder. Each editor will have their own project file.

In a nutshell, the white paper makes it clear how to enable the limited functionality available. Unfortunately, what is telling is what is not addressed:

• You can share media in a single location, but you can't have multiple editors ingesting to the same location. (You could with FCP 7, if you were careful about file names.)
• You can't share a single project at one time (one person editing video, and one person editing audio within the same project storyline).
• You can't ingest media and have it automatically pop up in another editor's workspace (as Avid has done for years).
• When you share media, there is no sharing of metadata you may add to the media within your own event database. Markers, keywords, collections, etc., are all visible only to one editor, no matter who may be sharing the media.

So it's nice to see this documented, but unfortunately there do not seem to be any magical new capabilities for advanced sharing capabilities revealed. Time to get those feature requests in!

Apple has posted a knowledge base article warning that a specific combination of Xsan client and a StorNext controllers may lead to data loss. The entire article is below.

Xsan 2.3: Update to StorNext SNFS v4.2.1 controller to avoid data loss issue

Symptoms

Xsan 2.3 clients (running OS X Lion or Lion Server v10.7.2 or earlier) that access filesystems hosted by controllers that use StorNext SNFS version 4.2.0 may experience data loss when renaming files on StorNext-hosted volumes.

A file may be unexpectedly deleted when renamed to a new name which differs only in the capitalization of the letters; for example, when changing "test" to "TEST".

Resolution

1. Update all StorNext FS controllers from version 4.2.0 to 4.2.1 or later.
2. Perform an orderly restart of all StorNext filesystems:
1. Unmount any StorNext volumes from all clients on the SAN.
2. Stop the StorNext volumes.
3. Start the StorNext volumes.
4. Mount those volumes on Xsan client systems once again.
5. Verify that the issue no longer occurs when renaming files.

Additional Information

This issue does not affect earlier Xsan client systems or SNFS software versions other than 4.2.0.

Apple today (well, tomorrow, technically) posted a terse knowledge base article confirming compatibility of Xsan 2 clients with ActiveSAN MDCs.

Xsan version	ActiveSAN 1.0
Xsan 2.1.1	√
Xsan 2.2, 2.2.1, 2.2.2	√
Xsan 2.3	√

It's not every day that Apple brings a new manufacturer into the fold. Congratulations, Active Storage!

Not bad for a .0.1 update. The announcements lists these features:

• Media Stems Export
• Rich XML Support
• Custom Starting Timecode
• Full-screen View in Lion
• One-step Transitions on Connected Clips
• GPU-accelerated export
• New Theme: Tribute
• Camera Import SDK
• Projects and Events on Xsan

About the Xsan support, Apple notes:

Create and edit your Final Cut Pro X projects and Events on Xsan. Ideal for multi-user workflows, you can import media through Final Cut Pro X and place it directly on the SAN. Multiple users can access the same source media, and each editor can create separate projects and Events on the SAN. Users can then edit from any system attached to the SAN, making it easy to move between computers and continue working.

So no shared timelines (wait! no timelines at all! I forgot.), but it sounds like the same Xsan support in prior versions of FCP.

Finally, and this is the first time I remember Apple doing this, they pre-announced two features. "Coming in early 2012: Multicam Editing, Broadcast-Quality Video Monitoring."

Apple posted a minor update to Xsan for Snow Leopard today, version 2.2.2. From the release notes:

The Xsan 2.2.2 Filesystem Update is recommended for all Mac OS X v10.6 Snow Leopard-based Xsan 2.2 systems. This update improves general file system reliability and

improves file system reliability when the filesystem is highly fragmented

improves file system reliability when unmounting a volume

improves file system reliability when running snfsdefrag

improves file system reliability when native extended attributes are enabled

improves Finder reliability when browsing a volume that is highly fragmented

allows Xsan Admin to create new volumes when more than 100 fsm processes are running

The compatibility matrices for Xsan, StorNext, and Grass Valley K2 MDCs have also been updated to reference the update.

Xsan 2.3 remains a Lion exclusive.