Creative COW's LinkedIn GroupCreative COW's Facebook PageCreative COW on TwitterCreative COW's Google+ PageCreative COW on YouTube
APPLE XSAN:HomeXsan ForumSAN TutorialsSAN Forum

Best Practices when it comes to XSAN 2

COW Forums : Apple Xsan

<< PREVIOUS   •   VIEW ALL   •   PRINT   •   NEXT >>
Social ShareSend Email MessageShare on FacebookShare on TwitterShare on LinkedInComment
Mike ZimbardBest Practices when it comes to XSAN 2
by on May 21, 2008 at 1:57:25 am

Our XSAN 2 is in the process of being built from the ground up and we have a great Apple IT company doing the install. They are phenomenal when it comes to the server backend and networking, but in terms of actual workflow questions I wanted to throw a couple of things out to the forum.

For us a typical project will have 1 or 2 designers and an Editor. In our current setup all of our edit room Power Macs are fibre connected to their own Raid and all of our design and graphics Macs have internal local SATA storage. So when a designer is working on a file, they have a local drive with their process work but the finished file is sent off to the editor who places the file on his RAID in the appropriate asset folder of the specific job. I envisioned the XSAN as being a common pool for all of us to work from that would ultimately do away with any kind of local storage entirely, however, a couple of things I'm hearing from Apple in terms of "best practice" are confusing me in this regard.

1. Apple recommends that when an Editor wants to open a Final Cut project they should copy the file off of the XSAN to their local hard drive, then revise their timeline and then copy the file back to the XSAN when work is finished. Is this necessary? What is the reason for this?

2. When any photoshop or illustrator file is going to be modified, it should also be copied off the XSAN, worked on locally , and then copied back when completed. Is this necessary? What is the reason for this?

3. Render files should not be located on the XSAN. Instead, an Editor should have an internal scratch SATA drive where all render files will be written. This does make some sense to me when it comes to fragmentation issues, because you probably wouldn't want all those tiny little files taking up room on your XSAN, however, what happens when you're in 10-bit Uncompressed HD and you render sections of your FCP Timeline. There's no way a little SATA drive will be able to sustain playback over those sections. How do you deal with uncompressed HD render files? Can those be written to the SAN or will these cause fragmentation problems?

These all seem very bizarre to me. What's the point of this incredibly powerful fibre channel SAN that is supposed to be a streamlined way for artists/editors to work, when you have to keep copying files on and off and need to still utilize local drives to store certain files? Is this just what Apple recommends, or is this really the right way to work if I want to keep us relatively problem free? It's obviously easy enough for us to do and with the "Check In/Check" features of Final Cut server it should really be a breeze, but I'm just trying to understand why Apple would design a system that still relies on local storage and has all of these little caveats. This wasn't exactly the XSAN I envisioned. Can anyone enlighten me? Any info is greatly appreciated. Thanks.

- Mike

Return to posts index
Reply   Like  

Bob ZelinRe: Best Practices when it comes to XSAN 2
by on May 22, 2008 at 11:28:46 pm

I greatly value your post, as I have heard the EXACT SAME RULES for other manufacturers of SAN systems. This validates the fact that as of 2008, there is limited bandwidth, and while everything "should work", to insure maximum performance, you should follow the rules that you have stated yourself in this email.

What does this mean -it means that the "incredibly powerful SAN" is really not that powerful with multiple users, that need to all do multiple streams of hi data rate information.

Bob Zelin

Return to posts index
Reply   Like  

Peter WigginsRe: Best Practices when it comes to XSAN 2
by on May 23, 2008 at 11:38:02 am


1) This might be a hangover from the first version of Xsan which could corrupt FCP projects. I actually work the other way round now, the main project is on the San and I make a backup locally. This is so other users can see an updated project without the hassle of me having to keep uploading a refreshed file. Autosaves are local.

2) have had no problems what so ever reading/changing/writing PS or Ai files to Xsans.

3) The two Xsans I work on have the renders stored on the SAN, other editors need access to the render files rather than having to do their own. You are also right about your local drive, also your HD renders will slow down as your local drive will be the speed limiting factor.



Return to posts index
Reply   Like  

Jordan WoodsRe: Best Practices when it comes to XSAN 2
by on May 23, 2008 at 3:42:11 pm

The main reason for project files living away from your media is so if you loose your media you don't loose your project files!!! it is that simple. I have seen too many places work with project files on the san so they can share, but what happens over time is that editors become complacent and don't backup or pull the project files locally. Sure the san is running great for a year or two, but all of a sudden it drops a drive and nobody is there to replace it... then it drops another drive... now newest project files are gone and so is the media. But hey, if an editor is lazy enough to not backup the project file they were probably too lazy to correctly log their footage so recapturing the footage would be a joke anyway.

the other reasons are that these are small files and in the old xsan there was a belief that small "pingy" files clog up the sans ability to write real raw video files. I think that is a bit outdated if you are using serious 4gig technology and a good raid controller.


Return to posts index
Reply   Like  

Anders HaavieRe: Best Practices when it comes to XSAN 2
by on Jun 7, 2008 at 6:58:44 pm

We've had about once a month problems with fcp projects suddenly being corrupt on the san. (1.4.1) We are now upgrading our system to xsan2.0, and will probably give it a new try..



Return to posts index
Reply   Like  

<< PREVIOUS   •   VIEW ALL   •   PRINT   •   NEXT >>
Social ShareSend Email MessageShare on FacebookShare on TwitterShare on LinkedInComment


Creative COW LinkedIn GroupCreative COW Facebook PageCreative COW on Twitter
Social ShareSend Email MessageShare on FacebookShare on TwitterShare on LinkedInComment
© 2016 All rights are reserved. - Privacy Policy