* Jan Harkes <jaharkes_at_cs.cmu.edu> wrote:

<snip>

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

Well, if the directories are small, I don't see a big problem. 
When fetching an directory's status, there could be an bit for
getting the whole contents too: we just need a list of filenames
with there inode_id's and attributes. Should be well compressable.
We also could use an timestamp (or sth similar) to generate an
difference datagram. 

> 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 my case, this is not really an issue, since I've got just some
user profile stuff with less than 5 users per client. 

<snip>

> In many cases I don't really care about file attributes, for 
> instance I may try to run
>     /coda/coda.foo.bar/path/to/my/openoffice-installation/oowriter
> 
> 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/coda.foo.bar/path/to/my/gimp-installation, etc.)

Hmm, in this case, we just need 4x dir_stat() instead of 4x dir_get()

I see several ways to solve this:

* as soon as an directory is traversed (opendir() and readdir() calls),
  the client requests the whole rest of the dir, or maybe the next
  bunch of X entries.
  
* several directories could be flagged to be fetched completely 
  (similar to or maybe via hoard'ing)

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

What should this exactly help ?

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

hmm, the problem is: I often have to reinit venus because it fails
to start due errors in the RVM :(

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

Yeah, this works. But the fetch process is quite slow too.
It took several minutes to get an 1.5 MB file (XUL.mfasl from 
mozilla's profile) via an DSL link. FTP and scp are several times 
faster. Codacon's output looks like each data chunk has to be 
ackknowledged before the next is sent.


cu
-- 
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT service

  phone:     +49 36207 519931         www:       http://www.metux.de/
  fax:       +49 36207 519932         email:     contact_at_metux.de
  cellphone: +49 174 7066481
---------------------------------------------------------------------
 -- DSL ab 0 Euro. -- statische IP -- UUCP -- Hosting -- Webshops --
---------------------------------------------------------------------