On Wed, May 19, 2004 at 07:35:50PM +0530, Sundaram, Arunkumar wrote:
> > I believe there is an implicit assumption that write-write sharing is
> > uncommon.
> 
> Is there any thought to transparently support write-write sharing in CODA? 
> 
> We may apply collision detection algorithm (with little modification),
> when two or more clients are trying to simultaneously acquire
> write-lock for an object.

A client never informs the server that it intends to write until it
closes the file, and even then it might very well be disconnected or
write-disconnected. If write-write sharing is truly common, disconnected
operation is clearly useless and I personally don't see the point in
using Coda. Let NFS/AFS/CIFS/Lustre/etc. deal with such cases.

Collision detection does just that, it detects collisions and doesn't by
itself provide a solution.

We could either try to detect the collision before the fact and that way
prevent a conflicting update from occuring. This mean we need to check
in with the server before any write operation, which is a performance
hit and it is difficult to do if we intend to work disconnected. We
either lose disconnected writes, or we would have to preemptively lock
down everything a client has cached (write-permit?). But such a lock
pretty much makes the filesystem unusable for connected clients.
Especially if we assume a lot of write-write sharing.

The other solution is detecting the collisions after the fact, which is
what Coda does at the moment with the version vectors. When a collission
is detected we have to somehow deal with the conflicting updates. AFS
semantics is 'last writer wins'. But with disconnected operation the
last writer to the server might be some very old copy, and we can't rely
on the clients to always have a correct local clock. So the Coda
designers decided that the last writer simply gets a conflict, and to
use heuristical methods to resolve such conflicts.

Most directory operations are automatically resolved. Only permission
changes and cross-directory renames are still a problematic area. There
also is an existing framework for file conflicts (Application Specific
Resolvers), but that hasn't been worked on very much. Every solution in
this area is application specific. the ways we can merge conflicting
updates to an mbox file are very different compared to handling source
files, while object files can simple be discarded and rebuilt, etc.

Jan