[OpenAFS] R/W replication

Jeffrey Hutzelman jhutz@cmu.edu
Thu, 15 Feb 2001 16:37:49 -0500 (EST)


On 14 Feb 2001, Derek Atkins wrote:

> Resolving conflicts in an automatic manner can be, um, challenging.  I
> don't know how CODA does it, honestly.


It doesn't, really.  Coda makes the assumption (conciously or not) that
most of the time, there won't _be_ any actual conflicts.  This is usually
a safe assumption, since most files are only ever written to by one
person, or at least by one person at a time.  When there is a conflict
(two copies of a file have both been modified), the whole mess is kicked
up to the user to solve.

Conflict resolution is the hardest part of handling read/write replication
or (especially) disconnected mode.  Ubik handles it for databases through
the use of Kazar's quorum completion protocol, which insures that only one
copy of the database is writable at any given time, and that that copy
always has the most recent data.

Ted has proposed a similar solution for files, based on an ECC-like
sharing approach.  There are two problems with this approach.  The first
is that read performance gets _worse_, not better, with more replicas,
because you have to fetch from multiple servers in order to reconstruct
the actual data.  The second is that reads become less reliable, because
you now need a quorum of servers to read data, instead of only a single
server.  Unfortunately, that requirement is simply not acceptable in
practice -- which is why, over time, all three major Ubik-using databases
have been modified to use readany transactions for their read-only
operations.

-- Jeff