Hi.

On: Sun, 17 Feb 2002 23:56:51 -0500,
    Jan Harkes <jaharkes_at_cs.cmu.edu> wrote:

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

This doesn't seem to be as user-firendly as the "weekend trip" stories
in all the CODA paper suggest ;-)! - I'll take a look ...

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

Ok. Is in only a single replica. I'll ignore this.

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

By takeing a look to the network-traffic ;-). A little correction: For
reads I get 4-5MB/s from the server. For reintegration (after writes
in disconnected mode) venus trasmits 4-5MB/s to the server. But for
connected writes I only get 150kB/s and the processing that is writing
hangs until the transmission has finished. Doesn't venus sends the
whole file after the write has completely finished? And shouldn't this
happen in the same speed? And why is the writing process blocking
during this operation?

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

Ok. Thanks for the detailed explanation - (after reading so much Coda
docs - some twice ...) this part is clear ;-)

> Jan

k33p h4ck1n6

-- 

eMail:    rene.rebe_at_gmx.net
          rene_at_rocklinux.org

Homepage: http://drocklinux.dyndns.org/rene/

Anyone sending unwanted advertising e-mail to this address will be
charged $25 for network traffic and computing time. By extracting my
address from this message or its header, you agree to these terms.