On Tue, 15 Oct 2002, Ivan Popov wrote:

> Hello Kevin,
> 
> to avoid going into all details I am trying to find the critical one(s):
> I am a bit afraid you expect NFS- or SMBFS-like behaviour from Coda
> concerning latency.
> 
> On Tue, 15 Oct 2002, Kevin Atkinson wrote:
> 
> > machine.  Then copy the files which vary anywhere from (100 - 2000 MB)
> 
> > Consistent read and write throughput is also important, especially
> > when capturing video.  I expect read throughput to be consistent for
> > reading large files which are not yet in the cache so the playback
> > will be smooth.
> 
> The throughput on an open file is exactly that of the local filesystem -
> because the file *is* local, in the cache.
> 
> But a close() after writing and open() before reading will be very
> time-consuming. I haven't tried Coda on 100Mbit network but I can't
> expect over 7Mbyte/sec anyway, so when you start a playback of a 2000M
> file from Coda, you will have to wait 5 minutes at least (the first time).
> Similarly with ending a recording.

Ouch.  

So when a file is open for reading the *entire* file has to retrieve
before you can start reading?

And the when a file is closed the system call will block until the changes 
are committed back to the server?  If more than one server is used it has 
to write the changes to *both* server before the close call will return?

I didn't realize coda was like that.  I thought that when reading a file 
not yet in the cache the file will be read in on demand instead of all at 
once.  And when writing I expected the close call to return immanently.  
And the changes will get committed at the cache manual convenience.

If I under stand you correctly.  I don't think coda is an acceptable 
solution in this case.

If coda does indeed have these limitations, are there any plans on 
addressing them?

--- 
http://kevin.atkinson.dhs.org