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