Coda File System

Re: What happens if the SCM dies?

From: Jan Harkes <>
Date: Thu, 13 Dec 2001 18:03:50 -0500
On Thu, Dec 13, 2001 at 02:38:38PM -0800, David J. M. Karlsen wrote:
> <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
> <html>
> <head>
>  <title></title>
> </head>
> <body>
> Jan Harkes wrote:<br>

Could you fix you mailer, I am not a webbrowser.

>    <pre wrap=""><!----><br>If the SCM dies the only thing that is hindered 
>    is adding new<br>users/changing passwords and the creation of new 
>    volumes.</pre>
>    </blockquote>
> they can still authenticate as well? (eg. use clog?)

Only if you specified multiple server as 'rootservers' or 'authservers'
in /etc/coda/venus.conf. Venus and clog should just iterate through the
list until they hit a server that is running an auth2 daemon.

> Some things abount the README at the ftp site:<br>
> first: it's for version 4.6.1 - should't it just be removed?<br>

Probably, I obviously haven't looked at it since 4.6.1 was released.

> also:<br>
> it referres to a venus-setup script that does not exist.<br>

It exists in the RedHat package and on the BSD's, for Debian I've moved
all the functionality into debconf, so you can use 'dpkg-reconfigure
coda-client' to do the same thing. I probably should add a silly
wrapper-script called venus-setup to the Debian package that just calls

> it tells me to run createvol_rep after running vice-setup.<br>
> Is this wrong? Beacuse when I first went into /coda/&lt;myvol&gt; the 

Ehhh, my guess is that venus failed to start up and you created 'myvol'
on the local disk because /coda wasn't mounted.

> existed. I ran createvol_rep - and now it's not there anymore... Doesn't
> the vice-setup do the createvol_rep as well?<br>

No, it takes some time to start the server and createvol_rep will fail
as long as it isn't up and running. So you have to wait for 'File Server
started' to show up in /vice/srv/SrvLog, which makes it pretty hard to
write a reliable script that can do the same thing.

> second: the README says that the LOG has to be large - isn't this wrong?
> The RVM needs to be large - the LOG doesn't?<br>

The log needs to be big enough to handle the biggest transaction that
could occur. Normally 2MB seems to be ok.

> Else:<br>
> codasrv uses and awfaul amount of mem - (eg. equal to the size of RVM).<br>
> I thougth it just did this when using files for LOG/RVM (beacuse they are
> mmap'ed) - but when I switched over to using partitions - it uses the same
> amount anway - is there a way to awoid this - the testmachine has only got
> 64 megs.<br>

To guarantee that we don't mess with the on-disk RVM data during

Initially the RVM data is copied to memory, all modification are on the
in-memory copy and logged in the RVM log. Once in a while we truncate
the log by applying the pending modifications to the on-disk RVM data.
When a server starts it initially commits all logged operations to get
the on-disk data back in sync and then reloads the data into memory.

However, when you use files as a backing store for RVM, we can use a
private mmap. The advantages are, although the process size looks huge,
the system can simply drop and reload any unmodified pages from the RVM
data file. Once when we dirty the page it is copied to anonymous memory
and therefore has to be written to swap when there is memory pressure.
As normally large parts of RVM are not being modified, we are a lot
easier on the kernel's VM system when operating like this.

> (Does this have anyting to do with the privatemap=0/1 in the 
> /etc/coda/server.conf?)<br>

Yup, see explaination above.

Received on 2001-12-13 18:04:08