>> >Note that the contents of /vice/db/scm is compared to the contents
>> >of /vice/hostname which is used as the server name in the context
>> >of the Coda realm. This is valid for "coser" installations. 
>> 
>> This is unclear to me.  I do see that my coser based install of coda/vice 
>> server does, in fact, have both a vice/db/scm and a vice/hostname, and
>> they match. 
> 
> They match on the scm machine and do not match on all other ones.

Ok, so we would need to update "scm" [on all servers] to be the new SCM, and 
it would need to match that shown in /vice/hostname of the new SCM, 


>> Honestly, though, what breaks if the update daemon is down for a few 
>> seconds while we take them all down, update and start them again? 
> 
> It is account and volume management which is crippled while the servers
> can not synchronize the relevant data with each other. SCM is the machine
> to perform such operations on. If your former SCM machine is down you
> are already out of luck and taking down the update daemons on the other
> servers does not make things worse.

Indeed. 


> File service itself is not affected by update daemons being down.

Got it.  update daemons are only for coser to coser replication/updates. 


> Note that you most probably want to take back / recreate the server which
> used to be your SCM as soon as possible, as long as it hosts some volumes
> or volume replicas. It is not supported to run with reduced number of
> replicas indefinitely, the modification logs will fill up at some point.

Noted. 

What defines the modification log capacity?  Disk space?
Where are the modification logs so we could monitor them? 


Thank you for your time! 

Regards,
 -Don
{void}