-
File Error: Unknown File/Saving on a SAN issues
Trying to figure this out while I have some downtime. We’ve Got 3 FCP suites hooked up to a san. Each are running San 2.2. Anytime one of the computers goes offline (shutdown/restart/sleep etc). the other suites can no longer save the current project file to the san. It only affects FCP’s ability to save on the SAN…no other apps or the finder have any issues.
I’ve been reading other posts about over the past few days and haven’t found anything more than a couple workarounds like “saving as” to the desktop..then relaunching FCP.
It’s rather annoying to alert all the other editors when you need to reboot so they can save their projects and wait for your system to be back up.
Anyway the reason I’m posting is I noticed that the most recent posting about this issue was in 2008. I’m wondering if people were somehow able to resolve the issue and that’s why there weren’t any newer posts on the issue.
Along the same vein I was always under the assumption that project files should always remain on and be worked on from the system drive (not a drive where the media lives)…however when we got our SAN set up they told us to keep project files on the SAN. I assumed they knew what they were talking about…but I noticed several posts saying to bring the project onto your main drive while working on it and copy it to the SAN at the end of a session. What is the proper way to work with project files on a san?
thanks in advance
-mattyc -
4 Replies
-
This is a really common issue. Don’t run your project files from the san. Your problems will rapidly go away. Probably not the answer you want, but there are very well sussed out ways to work collaboratively with FCP and Xsan and this isn’t one of them.
There are a few really great reasons not to do this that I could spend all day on, but I’m going to try to keep this succinct.
When you say San 2.2, I’m making an assumption that you’re using Xsan, and this is classic collaborative FCP workflow confusion. Here are some basic rules, otherwise you’ll keep running into issues.
-Keep all shared media on the Xsan. This is what it’s designed for.
-Keep all cache files local (Waveform, Thumbnail, and autosave vault)
-Keep all render files local (video and audio)
-Keep all project files local (this is key).Note: the project files can LIVE on the san, but you need to save as locally before you start working on them. Use it as a organizational tool for your files, but don’t actively use them from the san volume.
A few reasons to work project files locally:
-Xsan was designed for big video blocks. When you hammer it with thousands of tiny r/w operations from render files or project files, you really destroy performance. Your raids and metadata were tuned (if they were set up properly) to heave around big blocks of media, not small files.
-You immediately run into all sorts of permissions issues, as well as an array of other errors (a common one is the one you’re seeing)
-Natural separation of media and project files. You don’t want to lose both should the xsan go down.I know people get away with working project files off the xsan, sometimes for long stretches of time, but as you’re seeing, it doesn’t always work. Collaborative FCP workflow is concurrent r/w access to the same media, and it doesn’t relate this way to project files. The Error: File Unknown messages go away immediately after working project files locally.
As a sidenote, you mentioned sleeping the xsan clients; do not sleep computers connected to the xsan, or any san for that matter. Completely disable sleep. This is best practice for any san setup.
-
Thanks…this is spot on the information I was looking for.
While the Macs are running xSan 2.2 to communicate with the San..I have no idea how the San is actually configured. It’s shared storage between 3 Final Cut suites and 2 Smoke suites.
[Craig Thomas Quinlan] “-Keep all render files local (video and audio)”
We were told to keep these on the SAN.
[Craig Thomas Quinlan] “you mentioned sleeping the xsan clients; do not sleep computers connected to the xsan, or any san for that matter. Completely disable sleep. This is best practice for any san setup.”
This is something they(the company who built it and who we pay for tech support)forgot to tell us…until we started noticing the problem. That makes me wonder how much other stuff they didn’t tell us because they didn’t know or just didn’t remember.
-mattyc
-
[Matt Callac] “We were told to keep these on the SAN. ”
Many people do. This point is strictly a performance consideration. If you’re using relatively low-bandwidth media you might never notice, but if you’re heaving around many streams of uncompressed HD across an Xsan and you litter the r/w ops with tiny render writes and cache writes, you take a performance hit.
There’s a very long list of tweaks that can be made to take an Xsan from good to excellent in terms of performance and stability. It’ll work fine with a lot of what you throw at it, but to really get the most out of it, there are some rules to follow.
-
Our experience has been that project files should not live on the shared storage.
This changes with FCP X and its new SAN capabilities. We’ve been testing Titanium as an iSCSI Xsan and FCP X will use it as a san volume. You can open project areas on the SAN volume and it correctly locks them so other FCP X users can’t come in and screw them up. It also lets you “detach” them so others can get to them.
This is not “volume” locking in the FibreJet sense. it’s directory locking. You can give any subdirectory on the SAN and it will lock it. It’s very nice.
Steve Modica
Small TreeSteve Modica
CTO, Small Tree Communications
Reply to this Discussion! Login or Sign Up