Coda File System

Recommendations from my talk

From: Dr A V Le Blanc <LeBlanc_at_mcc.ac.uk>
Date: Tue, 9 May 2000 14:33:57 +0100
Well, I've given my little presentation about Coda for the first time.
I intended to give the presentation using Star Office with the
files (both Star Office and the presentation itself) in Coda,
but the display at the venue was unable to show graphical output
from my borrowed notebook.  For those of you who are interested,
a web-version can be found at http://www.mcc.ac.uk/~zlsiial/coda/.

At the conclusion of the talk, I make some suggestions, some smaller
and some larger.  I am willing to help with some of the smaller
ones, and I'd like to propose the larger ones for discussion here.

Smaller suggestions:

The documentation needs revising.

I'd like to see a ca/copyacl subcommand in cfs.

I'd like to see an option to kclog which allows you to specify
a token lifetime shorter or longer than the default, being
anything from a few minutes to a few months.  This involves changes
to kauth2 as well as to kclog.

Slightly longer suggestions:

I'd like to see something like AFS's ptserver, volserver, and buserver;
that is, some way of handling users and groups, volume status, and
backup configuration remotely.  I realise that pdbtool is a relatively
new piece of Coda, but I don't think it goes far enough.  Moreover,
the ability to have users create and manage their own groups is
too good to miss.  Also, if the mechanism is such that you need
System:Administrators tokens to do certain things, that would be
all the better.  I'm uneasy as it is about having users able to
mess up things on a client with some of the more dangerous cfs
commands; I wish these were restricted to local root or something,
at least on machines where there may be several Coda users at
the same time.

Finally, I have a question.  Is it a good idea to replace the
single SCM with some sort of quorum voting as in AFS?  It sounds
like a good idea at first blush, though I am concerned by the
problems which it has in practice in AFS; I'd not like to see
Coda's incredible resilience impaired by tacking on something
that doesn't quite work as it should.

The paper concludes that Coda may be ready for production use
in limited cases, where there is (a) not a lot of data or
users, and (b) more need for high availability than for ease
of administration.  I also warn that it's not easy for unskilled
users to install and run.  The paper concludes with a note of
thanks to all of you, and to Jan Harkes in particular for all
the help I've had here.

     -- Owen
     LeBlanc_at_mcc.ac.uk
Received on 2000-05-09 09:35:53