NTFS file system for flame

Back with another question regarding file systems this time.

I have a dual boot machine Windows 10 Pro and Rocky Linux. I would like to seamlessly use a single project drive to work off for both machines. Currently I have a PCIe Raid card with:
x2 TB raid 0 (4TB in total) for jobs in windows
x2 TB raid 0 (4TB in total) for jobs in linux

Today I discovered I could read the NTFS drive from Linux which got me thinking. Could I stripe both those drives together to have one large 8TB volume and have both OS read and write to the same volume (not at the same time, I’m not using virtual machines)

I know that linux is case sensitive so as long as I don’t make a folder called jobs and another called Jobs then I won’t run into issues there on windows. But are there any other good reasons why not do this? Would there be a performance hit for flame reading/writing off NTFS?

Also on a slightly different note where does flame save it’s project files? I am used to working in a job->shot based file structure (nuke user) so all the project files, plates, renders etc are stored per shot. Does flame just dump everything in the framestore, cache, render project files in an indecipherable way or can you store each flame project within the root of a job folder? I am struggling to find any decent resources on basic workflows and understating the basic concepts of library, desktop, batch, reels etc… every tutorial video I have watched seems to almost assume you are familiar with this even the videos on the flame learning channel do not explain this particularly well.

I did start reading @cnoellert post Publishing / unmanaged framestore workflow AKA how to make smaller archives for those that don't archive good which seems to be the kind of setup I’m used to but I stumbled a bit on some of the terminology.

Short answer is, “in multiple places”.

/opt/Autodesk/project/[projectname]/ will reveal a project’s directory structure (every project has the same structure) with subdirectories for each module (colourcorrect, text, batch, etc.).

Within each module’s subdirectory there are further subdirectories which are there to accommodate other machines that might be using the same Workspace (usually Flare workstations).

If you’re the only artist working on the project then your Batch setups would live at:

Various low-level components of a project (clip databases, etc.) will be distributed across folders in /opt/Autodesk/.

Hey guys, thanks for that. So it actually stores it on your boot drive! Hmm is that a good thing? I guess if you reinstall your OS you just need to remember to copy it out or can you move the folder where it’s stored? What do you have in place for data backup of these files? Do you just sync that folder to an external drive/cloud? I am assuming when you archive that it takes a copy of the files from /opt/Audtodesk/project/[Project name]. Then once archived you just delete the project from your flame startup menu?

The the framestore is literally just cache and renders? any thing else in there

Hello Kia!

When you install Rocky Linux 8.5 ISO from our web site and DKU (latest version is now 17.2 released with Flame Family 2023.2 Update), you get the required component to read/write to various file system, including NTFS. So, no admin work to do to modify the environment which is good.

In the past, the driver had issues but these days it seems to be more stable so you should be able to share a volume between your Windows and Linux environment. YMMV. For safety purposes, I would probably keep all my Flame project data on your system drive (/opt/Autodesk/), use the RAID as storage location. Performance wise, that should be fine but test your workflows before going into production, as usual. If when you reboot the workstation the RAID is up and running, Flame should be happy.

As Chris stated, Flame keep data at various location. The project data is located in /opt/Autodesk/project/, the metadata of the storage is keep in /opt/Autodesk/clip//project and the actual media is at the location you have defined in the Volume Creation section of the Project Creation menu. All in all, this data is proprietary to our products. If you want to externalize data, you might want to use the Sequence Publish functionality of Media Export (look at Shot Publish presets), which can create shot based structure, including source media and Batch setups. This is the closest workflow to Nuke.

Have fun and report your experience.

1 Like

Hey @Slabrie thanks for your reply that’s great to know… Yes my raid is recognised in both OS’s so I will give it a go.

1 Like

Lemme know if there’s something I can do to help you out. This method of publish workflow combined with pattern browsing imports on your Nuke v%2d style renders is a very solid replacement for Heiro or Nuke Studio editorially speaking.

1 Like

I believe doing an rsync of /opt/Autodesk to a remote volume is regarded as good practice but defer to the command-line folks here for the finer details.