We seem to have run into the problem where we need our precious SSD space only for hosting the core/contrib files and were wanting to have user generated files stored on another somewhat cheaper storage device.

As such, how can we configure our BOA system to force user generated sites/*/files to an alternative mounted volume?
We'd like this to be automated so when sites are created the default forces this to occur?

I have my ideas on how I envisaged this will work but thought to throw it at the issue queue first.

Thanks.

Comments

Status:Active» Closed (works as designed)

Hardware setup is something beyond the scope of the project, but I guess you could mount /data/disk/o1 or even /data/disk on another partition/drive. You can't reliably mount just sites/foo.com/files, because the full path will change on migration - by the way, did yo notice that our directory naming suggests just that?

fair call. Currently we have SSD mounted to / covering the /data directory and a non SSD drive for backups mounted to /data/disk/o1/backups/.
I suppose I could symlink site directories from the SSD to non SSD easy enough but what would the default behaviour of a verify/clone/migrate task expected to be?

by the way, did yo notice that our directory naming suggests just that?
I'm not sure exactly what you're referring to?

/data/disk

In fact I was pondering wether to set up /data/ssd/o1 in the first instance of running BOA years back.
I noticed that you advertised the fact that user files were on non SSD disks for your own environment and that is what gave me the idea to question it.

Do you just symlink the files directory to another disk? How is it handled there?

We don't use symlinks for this. This would never work when you manage Aegir instances using separate VM guests on the OS level, so it is much more advanced under the hood to get it working properly. It is not as advanced as Apple's Fusion Drive, but almost there. But our hardware setup is not a part of the open source BOA project, which is still a simplified version of our own scripts we use to manage our environments.

I understand it's not part of the boa project so perhaps we should move this conversation to a commercial support email address at omega8.cc.
I have emailed through the website.

Thanks