This is rooted in the Google search "File System".
Coda from CMU;
Notes on reading The Coda Distributed File System.
A good deal of the hair in Code is to accommodate Unix file semantics.
More hair is in replicating servers to achieve availability.
That is a good way to get availability but I want to split the architecture here.
I want availability here too and when I get to that part of the problem I will come back and look at their solution.
Just now I want semantics between client and server.
Perhaps I can't split the two, but I am going to try first.
I don't know how they invoke the application savvy code that knows how to merge updates upon end of network partition.
The only theory I know seems beyond the state of the art.
For now I am going to ignore the feature of file systems participating in update resolution, even while admitting that it might be strategic.
The human participation aspect is even more complex in our application.
Here I consider contractual relations between file holders and their clients.
I skimmed a half dozen other web sites describing file systems and most of them spend most of the description on how to cope with Unix compatibility.
The most common enhancement is journalling.
I didn't see other new ideas there.
Coda has some interesting ideas but they are not germane to the scheme afoot which seeks a virtual disk rather than a virtual file system.