Coda File System

Re: CODA kernel module limitations...

From: Roland Mainz <>
Date: Tue, 17 Oct 2000 22:11:09 +0200
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 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:

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



  __ .  . __
 (o.\ \/ /.o)
  /O /==\ O\  MPEG specialist, C&&JAVA&&Sun&&Unix programmer
 (;O/ \/ \O;) TEL +49 641 99-13193 FAX +49 641 99-41359
Received on 2000-10-17 16:25:16