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