On Tue, Oct 17, 2000 at 06:39:51PM +0200, Roland Mainz wrote:
> and my idea, too (for example: venus decides at OPEN to access the
> remote file readonly but triggers the download into the cache in
> _parallel_. If download is complete it switches from remote to cached
> file).

Venus will probably never support that kind of operation, our
versionvector/callback mechanism wouldn't even come close to handling
it reliably. Any consistency guarantees would be gone, and disconnected
operation would suffer big time.

Imagine starting your XEmacs out of Coda, going home and trying to save
the document you were working on. However the code that happens to
handle saving has never been referenced before and xemacs segfaults.

> And it would allow other projects to use the same interface, either
> using cached operations, direct operations or both.

For direct operations, hack podfuk into a userspace nfs daemon. And yes,
there will be many difficulties getting it right. The simplifications
that the Coda kernel module uses allow us to concentrate on what we do
best, while the filesystem that stores the container files and the VM
system handle the rest of the picture (synchronizing read/write/mmap
operations on the same pages, write/truncate race conditions etc.)

Sorry, but I'm naturally negative of just about any block-level caching
proposals as far as Coda is concerned. The internal complexity of the
cache manager is already very high. But the code is GPL, so feel free to
attack it any way you want.

Jan