On Sun, 12 May 2002, Jan Harkes wrote:
> > The location of the runtime data needs to be straightened out. /usr/coda
>
> Look at debian/coda-client.postinst for an example on how all these
> paths can be redefined.
>
> > For config files, I prefer key value pairs, one per line, with a
> > provision for comments.  The location of all databases and writeable
>
> Did you see /usr/coda/venus.conf?

Yes, I did, once I got up the next morning and started finding where
/usr/coda/etc/vstab had disappeared to.  What you [already] did is exactly
what I was asking for.  That's what comes from believing old documentation.

> Every Coda binary seems to have it's own method of logfile rotation
> implemented, if at all.

Since my home machines are turned off each night, I just rotate the logs in
the startup script, before starting the respective daemon.  Rotation only
happens if the file is over a certain size and if the previous backup file
was modified on the previous calendar day (not today), or doesn't exist.

> > The procedure for flushing the client cache seems unreliable.  Here's a
>
> Ehh, we revalidate the version of all cached objects, objects that have
> been updated at the server are flushed. Objects that have been changed
> on the client are reintegrated. When an object has seen concurrent
> updates reintegration fails and the user needs to run repair.

I guess this is more leftovers from the old documentation.

> > Making changes to a replicated readonly volume is very intimidating.  It
>
> That's why they aren't really supported anymore in recent versions. Just
> use ACL's to protect a rw volume from updates.

So, that answers my question in the previous mail.

> > becoming isolated poll all recently heard from clients and servers, and
> > positively notify them that it's going down?  Similarly, Venus should
> > notify the servers that it's disconnecting.
>
> When I walk out of the range of my wireless network card I can hardly

Sorry, wrong terminology. I was thinking of a voluntary shutdown with the
network running, particularly when several machines were shutting down at
the same time. On a suspend-resume, my understanding is that the servers
will figure out eventually who has gotten disconnected, but you're right,
there's no way to avoid a timeout for that case.

> ? Files have several advantages, they can be mmapped, significantly
> reducing server startup times. On linux even raw device access goes
> through the pagecache, so the initial reasons for the decision to use
> raw devices are not really valid on current Linux kernels.

Good to hear it.  I'll cancel the plans to use a loopback device for the
RVM storage.

James F. Carter          Voice 310 825 2897    FAX 310 206 6673
UCLA-Mathnet;  6115 MSA; 405 Hilgard Ave.; Los Angeles, CA, USA  90095-1555
Email: jimc@math.ucla.edu    http://www.math.ucla.edu/~jimc (q.v. for PGP key)