Care must be taken when planning out a filesystem structure for concurrent use with multiple redundant services. The extra performance cost of shared storage can also be taken into account.

As I see it, files can be divided into the following categories:

Static Content

The majority of our storage space is filled up with media files, HTML, PDFs, etc. These can easily be served up from multiple simultaneous nodes. A shared filesystem is enough to keep all nodes synchronized, and failover (and back) is trivial.

Live Content

Usually database files, though any files which are held open for writing for extending periods of time can fit here. Because of the extended locking, we cannot serve the same file from multiple nodes simultaneously. It will make the most sense to keep live files on a local non-shared filesystem. Frequent archive dumps to the shared fs (and copying from the shared fs on startup) will keep the services backed up and (somewhat) in sync. Failover and back (and/or live mirroring) will need to be dealt with on a service by service basis.

Configuration Files

Binary executable files and other detritus needed to run each service should be installed and configured locally on each node. Where possible, configuration files should be kept on the shared fs and simply 'included' in the local configuration.

Log Files

Logs should be kept on the shared filesystem, but with filenames or paths that include the serving node's name.

Seeded Files

Seeded files are generated specifically for one node based on shared data, and should not be on the shared fs. Unlike live content, the seed data rarely changes. The generated file can be rebuilt easily, but generally does not need to be. An example might be a config file, with %HOSTNAME% replaced with the name of the serving node.

Notes on building a filesystem for the purpose

I wrote ["lmfs"] for this purpose, but fuse is simply not robust enough.

My current thinking is that a filesystem driver could be written from the ground up. The bottom layer of course is the block device.