On Tue, Oct 15, 2002 at 04:12:06PM -0400, Kevin Atkinson wrote:
> Ouch.  
> 
> So when a file is open for reading the *entire* file has to retrieve
> before you can start reading?
...
> 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 you're write-disconnected the operation will be logged and
reintegrated in the background.

But yes, Coda has the described semantics. It is very useful when you
expect to be disconnected often and it is better to just hoard a lot of
data into the local cache. This makes Coda a very nice filesystem for
laptops, and less suitable for more cluster like environments.

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

Not really, I like it the way it is :)

Coda is complicated enough just trying to deal with issues like
replication and disconnection with complete files, doing those things
with file fragments would be horrible both code-complexity wise and
conceptually it would have too many failure cases that cannot be dealt
with.

Imagine having only 8KB from the middle of a 2GB file in your local
cache, and trying to reintegrate that with servers that have a different
copy of the file, each of which is not identical to whatever file you
grabbed that 8KB from in the first place. Or what if we're just trying
to read the next block while the version on the servers was updated.

All this, and you'd lose the close to local-disk performance on cached
file accesses as well, because we suddenly have to double check every
read/write access.

Jan