Smoke on a SAN?
Anyone running Smoke on a SAN yet?
I have a feeling there is nothing unique to this; you would just set your Autodesk Media Storage device to a SAN drive.
Although, I think you would need each machine to have their own directory; I don't think they could share a common one.
I'm also pretty sure all original camera masters and shared media files would have to stay in shared directories -- not individual Media Storage drives.
Anyhow, I doubt there is a best practices on this yet; I don't think anyone was using multiple Smoke machines in a shared editing environment before.
It appears that Smoke is going to need a local "scratch" drive.
It's the nature of the frame based renders.
I think you're right. I can't even get Smoke to see a network drive, only local. For me, this is the main limiting factor of Smoke. Not just the potential difficulty using shared storage. Even if that were not an issue, I'm used to a workflow where many artists can see and access the same source files and work simultaneously on the same piece of footage. Editing, compositing, tracking, color correction - experts in every room doing what they do best. As opposed to the all-in-one approach of Smoke, which is a wonderful thing for some jobs with a really talented generalist at the controls, but maybe not so much for collaboration.
But - that won't keep me from buying it. And I hope I'm wrong, and there are collaboration tools that I'm just not aware of.
Edit at Joe's
Things work fine until you have to render.
Smoke works on the SAN, but performance is abysmal.
Since everything is frame based renders, that means the metadata calls are many, and performance suffers to the point of unusable.
If this (Smoke) is the way we go, it means that renders will have to go to some sort of local storage. The bulk of the camera media can stay on the SAN.
A color correction render on the SAN stifles CPU to 150%.
Move the rendering to a local drive and CPU shoots to 900-1000%.
The rendered material won't even playback on the SAN, but playback perfectly from local storage.
We'll see how that shakes out for us.
I appreciate the efficiency of the frame based renders, but it might not work with our current architecture.
Yep, I did the test on our XSAN, no problemas.
[Helge Tjelta] "Yep, I did the test on our XSAN, no problemas.
Did you render something and playback?
Is XSan OK with image sequences?
Upon installation, Autodesk recommends to turn off indexing of the media folder. Like Jeremy says, I have a feeling you don't want the metadata overhead on shared storage. It's probably best to have a fast local disk that you use on each Smoke machine for cache.
So you basically, never let Smoke create / manage intermediates. You just render to an external disk and share source material on the SAN. That does enable multiple artists working off the same source media.
I have a feeling that any other kind of sharing -- say projects where different artists can work on different pieces of a timeline/cfx -- isn't going to be possible.
Even if your media cache drive were on the SAN, what is in it is pretty incomprehensible for another editor to use in a different project. The major benefit would be having someone on a different machine open up an archived project and having all the renders there to work from. But from what I understand, you can create an archive with all the renders inside of it which can be passed between machines. So I don't see a really need for a SAN based cache.
[Shawn Larkin] " So I don't see a really need for a SAN based cache."
Except it's the biggest, fastest, most expensive and reliable array in our shop. The reason for investing in a proper SAN was to get away from the local storage madness.
If each machine needs a local cache (which I think stores project info too) this will mean you'll need something fairly fast, large, and protected. There's not a lot of rt in Smoke so that means lots of renders.
Also, if you choose to use Smoke's sweet Proxy system, all of that media will be on the local storage.
If MacPros as we know them are going the way of the dodo, this means that we can't shove a wad of local drives in an iMac and you're left with Thunderbolt.
I'm all for Thunderbolt, but this now means I'll have a Thunderbolt to fibre adapter, an ioXT or similar video output device, and now another local cache array hanging off of it as well. I hope all of that is possible. It can't even be tested as the ATTO boxes aren't released yet.
In particular, metaSAN recommends a dedicated image sequence volume, which I suppose could be possible, but we would personally have to completely restripe our array, and probably keep restriping the Smoke cache due to fragmentation.
I haven't checked in to multiple stations yet, as first thing is first, and first it seems my SAN isn't working well for rendered playback.
I'd really love to hear if people actually use SANs in a Smoke environment and see how they have it setup. I've asked over in The Area, and no response there either so maybe it's uncommon.
Juan Salvo said on Twitter yesterday that XSan completely shut down when installing Smoke, he uninstalled Smoke and performance restored. It was probably due to the indexing, but not being able to index your main media folder seems rather limiting, but perhaps I'm holding it wrong.
Yes, this is definitely going to be an issue if Smoke is making an effort to compete in the pro NLE MC/FCP space.
I have Smoke 2012, and we currently use it for finishing only. I can see the networks as sources, but I usually consolidate to my local RAID before finishing a project.
If we had multiple systems, it's pretty easy to MOVE a project from one system to another, but not for simultaneous collaboration - 2 editors, assistant, MoGrfx, etc. - all quickly and easily sharing each other's bins & sequences, etc.
2013 changes much of the project/library structure, and I haven't had a chance to dig into it too deeply yet - but I don't think it will be as fluid as Avid Unity/Editshare for FCP, etc...
ALSO - frame based rendering is more challenging on a SAN. Left in its' default behavior, the Mac OS may scatter image sequences in any available space on the drive, which means the drive has to jump all around the platter looking for the next image.
I know Editshare has an "DPX mode" so that it will write individual files to the drive in an unfragmented way - so it might be an acceptable scratch disc for ProRes, but I have no idea if/how multiple Smoke's could point to the same media space and share the "Autodesk Media" folder.
These are all great points.
I think Autodesk is a ways away from recommending SMAC for true collaboration editorial. I mean, they have so much to do just to go to market -- I've had a lot of crashes and stalls on beta 1 and seen tons of room for improvement -- and this first release is a really for one-off / all-in-one environments.
Like, they would have to really plot out offline workflows to make this work for a lot of shops as a primary editor.
As to the burden of having another fast storage (array) connected locally, I don't think that's much of a big deal these days IF you go Thunderbolt and no MacPro, which is where this release seems to be targeted at (have you seen the ads?). Also, I really don't want a ton of single frame renders on my SAN. I prefer to have my fast cache local and place my project archive and final render on the SAN for safe keeping.