Can anyone point me to a white paper, blog post, thread, etc. that describes the benefits of switching to external container storage?
Also, is there any way of doing the conversion purely server-side? My client has just shy of 100K records, approximately 70% have 2 - 16 images embedded. For a file size approaching 60GB.
Remote Containers are newer than embedded as a feature and it is more efficient at retrieving the container content; it's faster.
it has tremendous benefit for keeping the FM file size down and making backups and overall disk usage A LOT more efficient. That's because of the hard-linking it does under the hood. If you are not familiar with that, ask away.
Much as I like your process, it is not quite what I need. I'd like to convert the containers to external storage, without monopolizing the system, maxing out the network, or locking up my own computer.
I see a 2 alternatives:
Bite the bullet and just do it.
Create new, externally stored containers then move the images from one to the other. (This could be done on the server asynchronously/over night.)
To be honest, I'm leaning toward option 2 if only because it means that I can re-vamp the structure (i.e. instead of having 16 container fields on each record, create a related table of records).
I'd value any all feedback or wisdom you (or anyone else) would like to share!
instead of having 16 container fields on each record, create a related table of records
One bit of wisdom that I've encountered as it relates to this is to dynamically set the external container folder path by date, so that the external container folder doesn't get too full of loose container files, which makes it slow to view and browse on the server machine's file explorer. Rather, it will produce a folder hierarchy like year/month/day.
instead of having 16 container fields on each record, create a related table of records
Do that.
@jwilling's suggestion to pigeon hole the content by date is good, though I haven't had a situation where it was necessary to go down to day. Year/month has been sufficient.
The trick for reliable transfer has always been to give the server time to do its own thing. If you allow the script to run unimpeded it can choke your resources and you'll get copy failures. You want to ensure that all the file i/o succeeds (and there can be a lot of system activity associated with all this).
The last time I had to do this we set up a workstation to run the process and left it alone. We had created a table for logging the process and installed a script timer to provide a pause between each run of the script. There were tens of thousands of records, several GB of data. It took forever but it worked.