(Illustration by Gaich Muramatsu)
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. JanReceived on 2002-10-15 16:36:25