Is anyone using FCPX in a SAN environment with NTFS/Windows storage?

[Bob Zelin]

isn’t your real question “how do I get MetaSAN to work with FCP-X? ”

You need to get NFS working for FCP-X to see your system. That’s it. That’s how it’s done on any of these systems.

Bob Zelin

Bob Zelin
Rescue 1, Inc.
maxavid@cfl.rr.com

[Jeremy Garchow]

[Bob Zelin] “isn’t your real question “how do I get MetaSAN to work with FCP-X? “”

No, it isn’t.

I am asking if anyone is working with FCPX Libraries, in a SAN environment, where the main storage is formatted as NTFS (not NFS file shares).

[Bob Zelin]

you can have NTFS file storage, but your NETWORK PROTOCOL must be NFS, not SMB (since you are using a PC server). The native default protocol of a PC server is SMB, not NFS.

Bob Zelin

Bob Zelin
Rescue 1, Inc.
maxavid@cfl.rr.com

[Jeremy Garchow]

I have metaSAN. It is working terrifically. That’s not the problem.

Let me ask a different way. Have you ever tried to copy and fcpbundle to/from NTFS storage?

Have you ever duplicated an fcpbundle on a windows machine (like a boot drive)?

[Neil Smith]

If you have an Xsan FC SAN set up with StorNext client on the Windows machine it will work … FCP X is only designed to share projects in an Apple Xsan shared storage environment .. it will not work across other protocols … it’s the only way Apple can guarantee performance levels and data integrity.

Xsan (which Apple OEM from Quantum who sell the StorNext SAN system) writes its own File System to the RAID volumes so you will lose your NTFS and HFS+ partitions .. make sure you back up all your data first 😉

metaSAN does not use its own propriety File System but writes a ‘Traffic Cop” bit of code to each SAN Volume which manages the Read/Write priorities and file locking plus maintaining the Volume Directory integrity. If you want to stop using metaSAN you simple disengage the “traffic cop” and your native File System takes over and you keep all your existing data … if you want to stop using Xsan/StorNext you have to completely re-format your RAIDS back to NTFS or HFS+ and lose all your data.

Neil

Neil Smith
CEO
LumaForge LLC
high performance workflow
323-850-3550
http://www.lumaforge.com

[Jeremy Garchow]

Hi and thanks. I think I may have asked the wrong questions.

I have metaSAN/LAN, it is working with FCPX. metaSAN has it’s own project protection system that we can use if we need it, or we don’t have to use it. Mostly, libraries stay local.

What I am running in to is that non zipped fcpbundle file transfers to/from the SAN take a very long time due to the explosion of very tiny files inside each fcpbundle and I am wondering if it is due to Windows being in the mix (our system includes a Windows metadata master). If i remove those tiny files before the transfer, and the fcpbuncle is full of proxy media (bigger files), the transfer goes very fast.

I can completely remove any metaSAN involvement in the process (like extract a zipped fcpbundle to the desktop of the Windows master). The zipped file transfers quickly, the unzipped file takes forever to extract or duplicate. Watching the files it gets stuck on are all the little cache, render, and reference files inside the bundles.

This only happens on NTFS storage, with or without metaSAN. Transferring or duplicating the same files on local Mac computers is totally fine. I am also talking with our vendor, I have spoken with the ever helpful Tiger, and now I am looking further out to the community to see if anyone else sees what I am seeing in order to help me identify this problem. I think I must be the only one in the world with this setup and stupid enough to try and make FCPX work.

Or perhaps, this problem is simply localized to my specific machine.

So, have you tried to copy an fcpbundle to a windows formatted storage? What happens?