Jan Harkes <jaharkes_at_cs.cmu.edu> writes:

> On Wed, May 04, 2016 at 07:43:46PM -0400, Greg Troxel wrote:
>>   I think it's critical to have a FUSE client so that coda can run
>>   anywhere that supports FUSE (the high-level interface, preferably).  I
>>   think it's perfectly ok if performance suffers a bit for this; working
>>   at 25% speed is 90% of the utility function for me, if not 95%.  And
>>   with modern CPUs the performane issues are not going to be a big deal;
>>   glusterfs on NetBSD (userspace FS, FUSE) is doing most of 1 Gb/s.  I
>>   think it's fine to have in-kernel implementations for those that
>>   really care about speed, but it seems the number of supported
>>   platforms has dwindled to Linux and NetBSD.
>
> Fuse would be nice, but its support is very on-off across platforms and
> it will never be possible to extend the fuse api with a cross-platform
> pioctl style interface, so pioctls would have to get implemented as some
> sort of virtual filesystem (similar to /proc /sys) probably somewhere
> under the same /coda root, we already use a hidden /coda/.CONTROL for
> global pioctls, so maybe something like that could become a root
> directory for a pioctl-fs where writing/reading virtual files would
> replace the current set of ioctl operations and still maintain the
> proper kernel-level tagging of user identity, which is more important
> than ever with namespaces you cannot just connect over a tcp or unix
> domain socket and prove you are in the same filesystem namespace as your
> /coda mountpoint. Again, this is a big project.

My understanding is that FUSE works fine on Linux, FreeBSD, NetBSD,
OpenBSD, OS X, OpenSolaris, and Android.  I realize that leaves out
Windows.  And it leaves out iOS, but Apple's policies will keep Coda out
of the iOS App Store anyway.  What platforms do you think it doesn't
work on (besides windows and iOS)?  And for any of those, why is making
FUSE work harder than making a coda kernel module work?

Most filesystems have a fuse implementation, and people have figured out
how to make those work.  Yes, pioctl could be some sort of magic path.
Or perhaps a plain ioctl with private codepoints can be passed through
to venus.  I think this is just something to be figured out, not a
reason why it can't be done.  I see what you mean about providing
identity, but one could always have the user program obtain a key or
auth token via a magic path and use that to authenticate a user/venus
channel.  But magic paths seem like an ok solution.

Agreed that it's big to do this.  But the other side of the coin is
implementing/porting and maintaining kernel modules for a very large
number of systems.

For me, if I can't run coda on all the systems I use, then it just
doesn't work.  So I tried out unison, and I am now using Syncthing
instead.  My take on requirements for coda is that being able to run it
pretty much everywhere (except Windows) is the biggest requirement, and
that security and reliability come next, and performance (assuming it's
>= 25% of native for things in the cache) is last.