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

Hi,

> I'm not too concerned with the amount of data on the wire, adding
> attribute information of all children of a small directory along with
> the directory data is possible. However in the Coda cache those
> attributes are not stored as directory data, but as file-objects with
> only attribute information. And the cache has a limited number of
> file-objects so we would have to throw out existing objects to make
> room for this (possibly never used) attribute information

So we could either increase the size of the filetable (maybe such 
partial information could be stored a little bit more efficient)
or aditionally store these relies as file-data.

<snip>
> > > 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()
> 
> No, we do need the directory contents to look up the object identifier
> of the next path component so we do need 4x dir_get().

hmmpf. best would be if the kernel could directly open the subdir
(aka pass this call to the fs) ... I imagine such things would get
tricky with certain mount situations. 

An way out could be, trimming down the file information exactly those
required here (->name,inode_id,inode_type) and send them along with
the first reply, maybe with some recursion, when it looks like an 
directory traversal.

> When you use /bin/ls (or unalias ls) you miss out on the pretty colors,
> but ls will only call opendir/readdir/closedir and it is done. It
> doesn't need to call stat on all the children.

Because it explicitly stat()'s each file for the right coloring ?

<snip>

> That is strange, I rarely need reinit. Could you send me a log of such a
> failing restart. Rotate the logfiles and restart venus with a high log
> level,
>     vutil -swap
>     venus -d 100
> 
> (venus will not detach from the console)

Ok.

> Another trick when you have to reinit venus but you are behind a slow
> link. It is possible to use lookaside to avoid having to refetch file
> contents. Venus will only get directory data and attributes.
> 
>     # move the old cache directory aside
>     mv /usr/coda/venus.cache /usr/coda/venus.old
>     mkdir /usr/coda/venus.cache
> 
>     # create a lookaside index
>     mklka /usr/coda/venus.lka /usr/coda/venus.old
> 
>     # reinitialize venus
>     venus -init
> 
>     # tell venus where the lookaside index is located
>     cfs lka +/usr/coda/venus.lka

In other words: use cached data from an old cache ?

> > 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.
> 
> There is some windowing, but the window has a fixed size. We send 8 1KB
> packets at a time and send the next set of 8 around the time we expect
> the ACK (without actually waiting for the ack). We do this up to 4
> times, and then retransmit the first unacknowledged packet until at
> least some of those 32-packets were acked. If any packets were lost they
> are selectively retransmitted and we continue advancing the window. This
> is roughly what happens, the details may vary slightly (i.e. we actually
> retransmit the first unacknowledged packet every time we advance the
> window, etc).
> 
> But the maximum window is at most 32KB, and if your link has high
> bandwidth combined with high latency we can't fill the pipe as well as
> TCP does. Still a 32KB window with 100ms latency should be able to fill
> a 2.5Mbit/s link, I'm seeing closer to 10ms from home to CMU so I'm able
> to fully utilize the available bandwidth. Of course if your latencies
> are in the order of 2 seconds we will never be able to push more than
> about 128Kbit/s, and on a faster link that would definitely make it look
> like SFTP is doing a stop and wait data transfer.

Okay. Is it possible to increase this window ? 
BTW: why isn't just TCP used for longer transmissions ? TCP seems to 
be quite advanced and can be tweaked for special needs.


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