Hauke Fath <hf_at_spg.tu-darmstadt.de> writes:

> On Tue, 27 Jan 2015 16:11:38 -0500, Greg Troxel wrote:
>> Also, there are solaris patches just arrived in pkgsrc.  I am unclear on
>> whether that means someone has the kernel code working,
>
> I am looking at how my group could use Coda to be less dependent on a 
> working network. Since the fileserver runs OI, I made Coda build there, 
> and only after the commit I realised there was an important bit missing 
> (<http://marc.info/?l=linux-coda&m=124181000316589&w=2> is the latest 
> news I could find).

To really be able to use coda, it has to be both reliable and portable.
Right now both are issues.

For portability, the problem is that it only runs on NetBSD and Linux,
as far as I know.

For reliability, it mostly works, but it's too easy to get venus hung
up.  On upgrading from NetBSD 5 to 6, I found two bugs.   One was a
regression in mmap/munmap of coda files in the kernel interface due to
some new assert.  I worked around that by disabling mmap.  The other is
that removing a directory leads to venus spinning, and I haven't
investigated.

I can see two ways forward:

  Make a FUSE interface for venus, so that it will run just about
  everywhere.*

  Create a new (FUSE-based) filesystem that is much like the current
  system, but can do write-disconnected caching based on some other
  filesystem that doesn't handle disconnects (sshfs, gluster).  Ideally
  it would work with stored metadata that can mostly function even if
  other users don't do this.  And maybe work extra well if all users do
  use it.  This is sort of like unison.

For your use case, I think you should probably add FUSE to venus.   This
is probably not exceedingly hard, and I suspect it is easier than
writing a kernel module.

People will probably say that this will cause performance problems; the
current kernel module forwards file operations in-kernel to the
container file, so read/write are at native speed.  That was probably
very important back in 1997, and there was no FUSE then.  But now,
gluster via FUSE achieves near Gigabit speeds on NetBSD.  And, I
personally would far rather have filesystem that works on all the
computers I want to use than to have it be fast on a few and totally
nonfunctional on the rest. But, if venus has the current kernel
interface and FUSE, those who want performance can use the present
interface, or implement it on more systems.

* I have no idea what that means for Windows.  But Windows is outside my
  definition of "just about everywhere"...