Coda File System

Re: coda very slow on roadwarrior

From: Jan Harkes <>
Date: Sat, 24 Feb 2007 21:30:09 -0500
On Sat, Feb 24, 2007 at 06:29:18PM +0100, Enrico Weigelt wrote:
> I'm currently experimenting w/ connecting an roadwarrior (DSL link,
> 100 .. 2000ms RTT) via coda. The traffic goes via an plain IPIP 
> tunnel, so no compression or encryption could interfer.
> The whole thing is very slow. Browsing through directores (not 
> cached yet) takes very long, codacon shows up that each file's
> stat'ed one by one with at least 1 second pause between.
> It looks like coda always runs requests serialized, which is bad
> if bandwidth is okay, but long RTT's.

The application is serializing here. If you use something like 'ls' it
will first perform an opendir/readdir series of systemcalls, and then
for every directory entry it calls stat(2) to give the directory entries
a pretty color.

The application blocks on each system call before it makes a new one.

In theory the Coda client could start to prefetch the attributes
whenever an application reads the directory contents, which at first may
seem very beneficial. However in the long run this is surprisingly often
a bad idea.

A client always has to work with a limited cache which it tries to keep
filled with the most valuable objects, we can't tell if the prefetched
objects are really 'worth' anything since they weren't cached (so the
user hasn't bothered about them before) and to make room for them in the
cache we have to throw out objects that we do know have some value.

In many cases I don't really care about file attributes, for instance I
may try to run

In which case, yes the shell will open each directory in the path while
it walks towards the binary I want to run. But I don't want my client to
waste precious network bandwidth (and cache space) by fetching all the
siblings of each path component.
    (such as /coda/, etc.)

> How can I make it work more smoothly ?

1. Use /bin/ls. 'ls' is probably an alias for 'ls --color', and calling
   the binary directly avoids the alias.

2. Have patience, the Coda cache is persistent and it will try to keep
   the most useful files around, so the next time 'ls' is called on a
   directory you've been to before it will be considerably faster.

3. Tell Coda what files you are actually interested in, that way it can
   prefetch them in the background, and also refresh them periodically
   if any of them have been updated on the servers. This is what we call
   'hoarding' and it is controlled by the hoard command, see 'man hoard'.
   You may have to set the 'primaryuser' option in /etc/coda/venus.conf
   to match your local userid.

Received on 2007-02-24 21:34:42