On Mon, Feb 18, 2002 at 03:49:25AM +0100, Rene Rebe wrote:
> 1. As written in the CFS Manual page 59 point 8 I can not get tokens
> when the client is disconnected. How should I work with CODA when I'm
> on a trip, in a train, car, plane, ... ?

As long as the client remains disconnected, it won't 'really' discard
the user's tokens so that you continue to have whatever access
permissions were cached at the time of disconnection.

However, venus doesn't persistently store token information, so the
token will be lost after a system shutdown/reboot.

For this case it is possible to create tokens for disconnected use.
'clog -tofile /local/somefile', and 'clog -fromfile /local/somefile'.
I still have to add some protection to these tokens, like encrypting
them with the user's password. These tokens still expire within 25
hours, so for the longer trips (and ofcourse even less secure), there is
an administrative tool "tokentool" that can be used by a Coda
administrator on the Coda servers to create a similar tokenfile that
contains a token with an 'arbitrary' expiry time.

This has not just the security issue of creating a token that is not
secured with a password, but it also weakens the longer term security
because we use the same session key for the lifetime of the token.
Normally the advise would be to switch session keys every N hours or M
megabytes of data (ssh and I believe ssl use N=2,M=2048), but we don't
have the session key renegotiation mechanism in RPC2 so we rely on the
user obtaining a new token once in a while.

> 2. On my server I get "Caution, replicated volume 0x1000001,
> resolution is turned off." What shouldt this tell me, and how can I
> fix it?

For end users that is a "don't care" kind of message whenever the volume
has only a single replica. For me it means that we still are trying to
create resolution log entries for singly replicated volumes somewhere in
the server code.

If you see this for a volume with multiple replicas, something is
definitely wrong, as the server won't be able to resolve conflicts
without such a log.

> 3. The read performance seem to be arround 2 MB/s which is ok for the
> beginning - but the write porformance seems to be arround 150kB/s
> which is slightly too slow ... Any ideas?

Ehhh, how did you measure write performance? Every operation that is
sent to the server has a certain overhead because of the overhead of RVM
transactions. It is mostly limited to the speed of the fsync system call
on the server. Linux is in fact pretty bad when fsyncing a multi
megabyte file which has only a few changes, each fsync can be in the
order of seconds. (and we call fsync at least once or twice for every
operation, create, store, chown, chmod, etc.)

If you force the client to work 'write-disconnected' most of the
transaction latency is hidden from the user. (cfs adaptive ; cfs wd) The
advantage is that the client performs reasonably well, but it only has a
limited space to log operations and the server is pretty much as slow
(actually between 10 and 100 times faster, but still a lot slower than
the client). Once the client runs out of logspace it will start
returning ENOSPC instead of blocking/forcing logged operations to the
server. Very annoying when unpacking a large(-ish) tarball. So make sure
to try to avoid write-disconnection when writing more data than the
client has cache available. (cfs wr ; cfs strong)

Jan