This is absolutely insane. These are non standard NFS options that ZERO ZERO other softwares need to operate correctly. Have you analyzed the performance impact of what setting these does in a studio environment with petabytes of data, 10s of millions of files and diverse workloads happening? From my searches, these options have performance a penalty.
I’ve been saying this from the start of the issue, why are you using the filesystem to maintain coherence of metadata when you have a PGSQL database, which its sole purpose and optimization is single source of realtime truth metadata, being used in the absolutely most basic, bare minimum way.
Flame has chosen the most fragile, convoluted path, which we are 1 year onto, and now this crap. We have to intentionally slow down on our NFS performance, consider how all the other functions of the facility are going to be impacted, and hope and pray that this is the one thing that fixes Flame. Nuke doesn’t care. Resolve just works. Maya, works. Every other aspect of our diverse studio, just works. But Flame, no it needs to have special NFS mount options because, instead of using an actual metadata optimized database, for metadata operations, you have to jam it into the Modification time of a file over NFS. And the documentation original started out at 1 second accuracy, and now you are stating sub-second accuracy.
This is a failed approach. And you guys keep doubling down on it for a year. It will never be optimal. It will never be reliable. The only sane approach is database. But Flame stopped at the 2 columns. Why even implement that? Might as well stick with the mono-file BerkleyDB.
Anyway. Flame 2025 it is. This is so lame, as to be basically un-believable this is where we are at.
I hope and pray that gen-AI rules, and puts us out of our misery.
