Interesting. I’ll have to play with it with their trial.
Path translation/convert to local path will be an issues I need to research too.
It just depends on how you set it up. If Lucid is your only storage then everyone who mounts the file space can be pathed the same regardless of where they are… you don’t need path translation at all. All the Macs and Linux boxes can mount at /Volumes/filespace.
Where it gets a little more complex is if you have a mixed storage environment—a nas and local clients to that nas and then remote clients who are using only lucid. Then you need to work out some strategies before hand.
Path translation is one that can work. Another is syncing from the nas and mounting lucid in remote clients at the same path as local clients mount the nas.
My only beef with path translation is that it’s kinda half baked. For example, it should work for bookmarks. Or file loads. There should be a path-translated list in the file browser that allows you to load material as though you are loading from the source path to keep things clean.
For example, say you’re translating /mnt/projects to /Volumes/projects. If you go to load material from /mnt/projects then you can’t. Because that path doesn’t exist, despite the fact that Flame know you’re translating it to /Volumes/projects. So you load material and save your setup but now it has material referencing /Volumes/projects so you need another rule on the boxes that mount /mnt/projects and things get one step messier. If we could navigate to the path translated paths and load as though they are local it would make things cleaner.
4 Likes
i am also trialing this and it seems to work fine.
Is there anything I can do to break it? 
we are on the same train here, unmanaged framestore is only playback cache but id still like a centralised project server 
…is always the sentence I hear just before users start getting issues 
5 Likes
Should i be seeing the physical location of the cache area ever fill up with media? I have a bunch of clips loaded in flame and just want to verify everything is working as expected. or do i have to pin? but i don’t know how to do that in linux with lucid. we are new to this workflow so any guidance would be helpful here.
I’d maybe speak to their support on this one , it might be doing some Hidden Folder voodoo type stuff. Ive been playing back full 4k 16bit EXR’s with no cache or Pin this afternoon I was very impressed (with a 1gig internet connection).
i think maybe once i pin (via command line) it will populate.
i agree though that for the most part the playback seems pretty good. still testing though. this is all very new. unfortunately the pinning via terminal is not working quite yet…working on it.
Once it’s pin and cashed, it’s up to the speed of the device that you’ve cached. The cache is all hidden. So don’t expect to look at it there. It’s all unhelpful managed media’s type situation.
Best thing you can do is install glances
sudo yum install glances
It’s like a free ice stat Pro for Lennox. After it installed type glances in a terminal and look at the top left for networking activity. That’ll give you an idea of what the network activity is happening on your box . Or of course, monitor it on your router.
1 Like
lucid cache files are in fact hidden, you can run
ls -lah /cache/location to see hidden stuff in a terminal
or run du -sh /cache/location to see the size used up .
one note on speed, the LucidFS thing actually has quiet a large performance hit on read and write speeds, so reading from your nvme directly can be a LOT faster than reading from lucid.
seems to be different per OS, its not as bad on macOS and Linux but pretty bad of a hit on Windows.
If I recall the cache is made up of the encrypted blocks, not actual files. That might explain the performance overhead?
In my experience it’s best to use flame framestore cache rather than the lucid pinning method.
The cache is excluded from archive procedures and provides the necessary performance for playback.
1 Like
This is what we recommend so playback is not affected.
2 Likes
do yo mean to just cache on import or whatever as if you were importing from a server?
I was under the impression that i couldn’t do that with lucid link. we tried it and it never would cache to my framestore. am i missing something here?
@blakieman - re: cacheing
Lucid Link can request a specific quantity of storage as cache from your OS and you determine where that is and how much, including on your fastest storage if you want.
The Lucid client can ‘pin’ data so that it does not get flushed if your cache experiences volatility.
Neither the cache nor the pinning are under the governance of flame.
They are completely separate from flame.
For best performance, make a big cache for Lucid, pin the data that you want to be less volatile.
Separately, use media->cache in flame to push your data to the framestore where you are more likely to retain the required performance characteristics.
If you are using an openclip workflow you can add the smart flag on your open clip files to automatically cache every version, including source segment openclips which feed your batch groups.
Then you archive and ignore any cache.
.
└── My-Workstation
├── Boot-Drive
├── My-Home-Drive
│ └── Lucid Cache
│ └── Pinned Data
└── RAID-Volume
└── mnt
└── StorageMedia
└── p0
└── My-Workstation
└── AutodeskMediaStorage
└── Cached-Files
1 Like
this is great. thanks so much.
we have pinning working just fine and have a system in place much like as you describe.
we are unable though to do any traditional caching to the framestore i.e.
“Separately, use media->cache in flame to push your data to the framestore where you are more likely to retain the required performance characteristics.”
that is not something i know how to do with lucid. i am only able to pin.
how did you get that to work?
caching still works from our server, but not from our lucid link.
The flame cache is not the same as Lucid Link cache or pinning.
If you separate your storage in terms of slower (OS, Home Directories) and faster (flame framestore) you use Media->Cache in flame, which is what you would have done in a legacy workflow.
The benefit of an openclip workflow is that you can cahce all versions of your sources and your comps to the flame framestore and hopefully guarantee client-facing performance
Happy to do a zoom to show you if you like, but not happy to make pictures and videos and post them - too buried in something else right now.
1 Like
i think i got it, now that you clarified it a bit more. i can take it from here. thank you so much for your time and response. really appreciate it!