On Wed, Jan 28, 2015 at 11:48:37AM -0500, Greg Troxel wrote:
> > <http://marc.info/?l=linux-coda&m=124181000316589&w=2> is the latest 
> > news
> 
> 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.

Sadly, this is correct, several platforms has lost the support with time.
The main reason seems to be that even the relatively simple Coda kernel part
is not "simple enough" to be correctly ported between OS versions
without a Coda-specific knowledge which developers generally lack.

Coda is still inside the moment 22 (too few users because of limited
development, too little development due to lack of competence, too little
people with competence because of too few users). Still it is alive and
performing reasonably - with no comparable replacement so we who depend
on it are kind of forced to keep it alive! :)

I wish we would do more than just "keep it alive".

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

Hope you find some more time to work on this. It would be just too bad
not having Coda on NetBSD.

> I can see two ways forward:
> 
>   Make a FUSE interface for venus, so that it will run just about
>   everywhere.*

Concerning "about everywhere" - I am unsure whether FUSE is portable to
the necessary degree, i.e. provides the necessary facilities "everywhere"
- Coda is a quite non-traditional file system while I _guess_ that FUSE
is implemented in different kernels in the first hand with the most
common file system abstraction in mind.

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

I do not wish to sound negative but feel some doubts nevertheless.

Would it really be easier to implement the Coda security and consistenly
model (in presence of disconnections) over a different file-system-like
storage, compared to talking to Coda-specific servers like we do now?

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

If done in a portable (not Solaris-specific) fashion a FUSE-Coda-client
would be certainly an extremely welcome contribution for other platforms
too. Otherwise, with Solaris kernel knowledge, a kernel module can
be easier.

> 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 would be happy to trade some performance against universality and
lower maintenance costs. I would happily trade even much more for a
fully user-space implementation, which is possible without FUSE and thus
without the superuser privileges.

The main problem is that we who need the functionality have no redundant
resources to do the development. In other words, the benefits of Coda
do not bring in enough money to make the development of Coda sustainable.

Research drove the development for quite a while (thanks Satya!)  but it
had different goals than to build a "production system". For the latter
nobody has invested the necessary amount. I have not any good answer to
how to solve this. A technical/conceptual superiority does not necessarily
imply adoption in a profit-driven infrastructure (because of the conflict
between the short-term survival and long term benefits).

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

Hardly a regression anyway - the last version of Windows (XP) which had
Coda is no longer with us. On the other side a Coda to Samba gateway on
Linux is "relatively trivial" :)

Rune