Replicated servers, milko?

[Jeffrey Hutzelman]

> (basically, what's needed is a set of modifications to the cache manager
> so that dirty chunks are not permanently discarded from the cache until
> after they've been "committed", which could occur after they've been
> replicated, or at least sync'ed to a shared disk.  The other thing that's

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.

> 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.

-- Jeff