I guess I was just thinking it would be a nice optimization for those
cases where clients are strongly connected and trying to access small
parts of huge files (bigger than cache). Its ability to operate in a
disconnected state is undoubtedly a great feature but not its only one
(scale, performance, etc). However I can understand how this would not
be trivial or even possible to implement without big architectural
changes - it would be nice in some situations though :) 

 -M.

On Tue, 2004-01-27 at 15:02, Stephen J. Turnbull wrote:
>     Mark> Are there any plans to fetch and cache blocks if the file is
>     Mark> too big to fit in the cache?
> 
> No.  That can't possibly work while you are disconnected.
> 
> If you want features that can only possibly be supported while
> connected, then you don't want Coda.  Coda is not a network or
> distributed file system as conventionally conceived.  It is a caching
> file system which allows a group of weakly connected hosts to
> transparently access a much larger "external" file system than any
> given client actually holds while connected, while permitting
> disconnected operation on the files in the cache with (almost)
> transparent semantics of operating on the "external" file system.
> 
> In many ways, Coda is more like an automated CVS without past version
> history than it is like SMB or NFS.  At least, I used to use CVS as a
> file replicator across hosts, but switched to Coda for applications
> where I don't care about the version history.  Rather, I'm interested
> in ensuring that the version on every host I use is always current (up
> to the last connection).