Jan Harkes 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.

Does this really work in all cases ? Why does http://atrey.karlin.mff.cuni.cz/~pavel/podfuk/podfuk.html claim that NFS doesn't fit the needs ? And: AFAIK noone outside Sun has written a working NFSv3 server implementation yet (there are some NFSv2 server implementations out - but none of them look as they can be used to hook my work on...), all other vendors licensed Sun's code... ;-(

I'm looking for something like this:

            glue
kernel_vfs<------->userspace_vfs(midnight commander vfs/gnome vfs/etc.)   

Anyone seen something like this (e.g. the "glue") ?

Forget performance problems for a few secs... I'm looking for a safe&portable way to hook-up new filesystems into a system. Writing kernel modules is not the right way - one mistake and the whole OS get'S killed. Bad.
Ideas ?

> 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.)

And so on. This would cause all kinds of problems which already exists in systems like DFS or cachefs(Solaris).

> 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.

Agreed... :-)

Bye,
Roland

-- 
  __ .  . __
 (o.\ \/ /.o) Roland.Mainz_at_informatik.med.uni-giessen.de
  \__\/\/__/  gisburn_at_informatik.med.uni-giessen.de
  /O /==\ O\  MPEG specialist, C&&JAVA&&Sun&&Unix programmer
 (;O/ \/ \O;) TEL +49 641 99-13193 FAX +49 641 99-41359