Optimizing FCP on Xsan Systems

Now that we've implemented a fully working SAN, there a few more tweaks to be done for each client node to ensure maximum throughput and minimal hassle when using FCP.

Keeping Login Computers Consistent

Centralized directories give most facilities the unique convenience of being able to log into any computer on the network as a particular user and having that user's data, preferences, Desktop pattern, and Desktop clutter come up on that computer. This phenomenon is called having network home folders. But as you read in our steps earlier, we explicitly created local home folders for our users, in order to satisfy FCP's sometimes quirky write requests.

Because our home folders will be created locally, creatives should log in to the same machines every time, in order to preserve their user experiences.

Since the directory is centralized, there is no harm in logging into someone else's computer with your user, but once you do, a new home folder is created on that machine, with brand-new subfolders, new preference files, and so on. So, if a creative ever does this and wonders where their Dock items are, you can explain what happened.

What Files Go Where?

A plethora of files are created in the course of an FCP project. Having read this far into the book, you'll no doubt have specific ideas about where these files should go. Slight adjustments have to be made when using Xsan in your workflow.

Project and Cache Files

Clearly, project files, waveform and thumbnail caches, and Autosave Vault files should be saved locally. Project files that will be shared for collaborative work can be copied to an appropriate Xsan volume folder once they have been created.

Capture Scratch and Stock Video

Setting Capture Scratch folders on Xsan volumes is absolutely encouraged. Even though you may want to set every client's Capture Scratch folder to the same folder on the volume, you should set up unique capture scratch folders per user. This allows more-structured organization of captured media.

Stock video files should also be located on the Xsan volume. Read further for ideas of affinity assignments for stock video files.

Stock Music and Sound Effects

Since the bandwidth requirements for music and sound effects are so low, and since a typical facility has so many of these files, their storage could be relegated to a regular file server, or a separate Xsan volume. This allows you to keep the performance-robbing hits for these files off of your video volume. You may also store the sound files on the Xsan volume, provided that they are copied locally before they are actually used within a project.

Render Files

We may want to immediately assign a certain folder of the SAN as our main Final Cut Pro scratch disk, render folders and all, as we have learned to do in other areas of this book. But alas, we might be disappointed with the Xsan's performance if we do so.

To understand why, remember the last time you did a long render. It took much longer to render that file than it took to play it back when you were done, right? Final Cut Pro's rendering engine simply opens up a QuickTime file, writes frames to that file as fast as it can render them, and then eventually closes the file when it's done. Sometimes, with very powerful machines and the rendering of still images, the QuickTime file can be created in less time than its playback speed. But in most cases, render times take much, much longer.

With Xsan, as this QuickTime render file remains open, little tiny hits on the Fibre network, especially from several users at once, will interfere with anyone else's ability to stream real-time clips.

One way to solve the issue is to create a separate LUN or LUNs, on a separate Xserve RAID controller, which can be assigned to a separate Storage Pool and Volume, dedicated to rendering. Because render files aren't as important as captured clips (they can always be remade), you could create RAID 0 LUNs to benefit from a small increase in performance.

An alternative, robust long-term solution for this issue is to create small direct-attached render arrays for your client machines.

Direct-Attached Render Arrays for Use with Xsan

Since some of you may be using high-bandwidth clips, this may require having small, high-speed direct-attached storage on your local machine for the very purpose of creating and playing back render files. The key point to remember is that render file storage almost never needs high-speed write capability, just reads. If that doesn't make sense, remember the scenario we just explored: render files almost always get created at much slower than real-time speeds, but then need to be played back in real time.

See Lesson 9 for more information on creating inexpensive small-sized high-speed storage for your systems.

Creating Affinities for Different Kinds of Media Files

As we explored in the planning section, you may want to create separate volumes, or specific storage pools within volumes, that have RAID levels other than 5 for specific kinds of media files.

For example, stock footage used in day-to-day projects almost never needs any kind of redundancy protection, since they can always be reloaded from tape, CD, or DVD back onto the SAN. They just need to be available at high speed. Therefore, storing them in a root-level folder with an affinity assignment to a RAID 0 storage pool is ideal.

Alternately, outputs of picture-lock edits, client approvals, or any other finished QuickTime file might get saved out to a folder that has an affinity to a RAID 1 storage pool. This ensures that these files can be accessed even when the primary storage goes down.

The Dreaded Umask

Because the Xsan volume is essentially a gigantic UNIX volume, it is governed by UNIX permissions rules. Therefore, the permissions of any file that is created on it, or copied to it, is determined by the umask, or user permissions mask, of the user creating or copying them.

The default umask setting for an OS X user is 022, and this number is used to offset the normal permission setting of a new folder or file, which is 666. That's not the sign of the devil, mind you; that's a simple numerical explanation that the user, his or her group, and the rest of the world can all read and write to the file.

If we subtract each number of the set 022 from its 666 counterpart, we get 644, which means that the user can read and write to the file, but the users' group and the rest of the world can only read from it.

This causes a problem with collaboration, especially when a group cannot place files inside of a folder that was created by one of its members, or if they can't save over a single collaborative FCP project that gets the incremental edits of a group of people.

How to fix it? There are several solutions.

One is to permanently reset the umask to 002, which would make all folders and files created by any Xsan user readable and writable by their groups. You can write a simple shell script and send it out to all your users to make the change permanent. Nifty shareware programs such as Marcel Bresink's TinkerTool (www.bresink.com/osx/TinkerTool.html) will do it in a nice GUI.

Another solution is to create an AppleScript droplet, or regularly running the application (chron script) that changes group permissions on all new files and folders on the Xsan volume on a regular basis.

In either case, knowledge is half the battle with this slightly annoying side-effect of collaborative storage.

Assigning Quotas to Ensure Adequate Space for Everyone

Xsan's Quotas feature is ideal for creating invisible fences inside of the volume, so that no particular user or group can hog more than their share of the storage.

In collaborative post-production environments, this will be essential to make sure that every person and project gets adequate space.

A sample quota implementation

The implementation of quotas is simple, and it is done directly in the Xsan Admin application. Users and groups can have "soft" quotas assigned that they must adhere to. Administrators can be notified by Xsan Admin via email or pager if any user or group exceeds their soft quota. After a certain time, these soft quotas turn to "hard" quotas, disabling any further writes until the particular user or group cleans up their act and gets their total space usage below their soft quota again. Users encountering this in the Finder get a 1425 write error to inform them of their inability to write to the SAN.

New to Xsan 1.1 is the Xsan User Quotas application, which allows your users to see where they stand on usage. Learn more about quota assignment in the Xsan Admin Users Guide.

Using the Bandwidth Limiter Inside Final Cut Pro

New in FCP 5 is the Limit Real-time Video To checkbox, which is in User Preferences. You can use it in conjunction with Xsan to limit bandwidth "hogging" from any individual client machine, by simply restricting the amount of real-time video to a certain MB/s value. If your current sequence needs more than the specified limit, the render bar turns red. Rendering at this point reduces the need to one stream. This feature is excellent for large implementations where a reasonable limit imposed on every machine yields greater performance for all. Use it by calculating the maximum number of streams needed multiplied by the data rate for that stream to arrive at the limit amount, which is placed in the User Preferences for that machine.