On Mon, Apr 12, 2010 at 01:56:28AM -0700, root wrote:
> >An entry for this host is needed in <server-directory>/db/servers
> >on the SCM.
...
> >Then all servers belonging to the same realm need to be restarted,
> >as they need to know about the new server.
> 
> Which services?  I hope not the codaservice itself -- maybe just the
> update services as was referenced in the disaster recovery thread?

Yes, the Coda server.

The reason is that Coda is using co-routine based threading, which has
quite a few advantages, for instance simpler locking/sharing semantics
because only one thread will execute at a time. But that same single
thread of execution is also a disadvantage as a blocking library or
system call will block the entire process. So Coda avoids doing some
typically blocking operations, such as DNS lookups, at runtime.

So the mapping of server names to ip-addresses happens on the server
who (when a clients wants to locate a volume) sends a list of replica
ip-addresses to the client. And the server does the DNS resolution of
these names only during startup. So when you add a new hostname to
/vice/db/servers, the Coda server process needs to be restarted so that
it can perform the DNS lookup and know about the new server when a
client asks for the location of a volume.

A problem with the server-side DNS lookups, besides that it only happens
on startup is that we currently only return a single ipv4 address for
each replica. Addresses are resolved as seen by the server, so the
server itself often resolves something like 127.0.0.1, which is useless
for clients, and if servers have some sort of dynamic ip-address, they
all will need to be restarted whenever a single address changes and
clients tend to hang on to the old addresses in their respective caches
way to long (i.e. don't use dynamic ip addresses for Coda servers).

Jan