Replicated servers, milko?

[Lyle Seaman]

> Hmm....  Interesting idea.  Of course, it's asking a lot for 
> the clients to
> keep track of changes until replication happens.  There are 
> also security
> implications if a server failure occurs after the client's 
> authentication
> has gone away.  Perhaps some kind of Ubik-like quorum-based 
> thing is needed
> to handle nearly-simultaneous updates to multiple read-write 
> copies of a
> volume. Unfortunately, I don't know how well this would perform in an
> environment where there are actually lots of writes going on.

It depends on how stringent you want your synchronization semantics to be.
If you want guaranteed read-write replication, the client has to keep track
of changes until the changes become "durable", in whatever form that takes.
At present, "durable" simply means resident in the sole server's buffer
cache.  If you use a quorum model of durability, then the client has to keep
track of all the changes until the quorum is reached.

> > needed is a callback and lock recovery protocol, so the new 
> server can
> > learn about which callbacks and locks have been granted 
> already.  One way
> 
> A simple way to accomplish this would be for the new server 
> to impose a
> minimum time before it accepts new locks or writes, starting 
> when it lost
> contact with the previous read-write master.  The idea is to 
> ensure that
> any locks or callbacks issued by the previous master have 
> timed out by the
> time the new master starts issuing locks or allowing changes.

Yes, that's the Sprite and DFS model. The problem with doing only that in
AFS is that the maximum callback interval is 4.5 hours.  Forcing servers to
be effectively read-only for the first 4+ hours of uptime is untenable.
Even with the DFS model, the server goes through a "token recovery period"
for a few minutes during which it is less than completely useful.  For
maximal availability, that recovery period needs to be minimal.