On Thu, May 05, 2016 at 10:36:30AM -0400, Greg Troxel wrote:
> Jan Harkes <jaharkes_at_cs.cmu.edu> writes:
> > Fuse would be nice, but its support is very on-off across platforms and
> 
> 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

When I last looked there were several windows fuse implementations, and
in the back of the mind I recall the OS X variant had broken because of
some kernel change.

But there were two ways to use fuse, and one, the high level api using
libfuse, which was the most portable across platforms used a separate
thread to handle each request which doesn't mesh well with Coda's LWP
threading and the low-level api was either not available for every
platform or needed platform specific tweaks, details are unclear.

I think fuse could be a cool alternative to the Coda kernel module and
probably is seeing more use and maintenance so over time it could become
the main api as long as pioctls and other coda-kernel-module specific
things (if there are any others) are dealt with.

The individual read/write accesses used to be an issue when systems were
single core and context switches were expensive. Each system call would
require saving the page table state for the user's process, then context
switching to the venus process, handling the IO, and context switching
back. And something like a write would involve the original data copy in
the app (1), copied to the kernel (2), copied in-kernel passing on the
upcall message queue (3), copied to venus (4), copied back to the kernel
for write out to the container file (5), actual copy to disk (6?).

Things have improved in modern kernels, cpu caches are larger, copies
are more efficient, context switch overhead is much improved, there is
zero-copy IO, we have multiple cores so both the app and venus can keep
running at the same time and available memory is measured in the
gigabytes instead of megabytes. We can push gigabytes per second as
individual reads or writes through a fuse filesystem, although having a
well behaved application using page-sized/page-aligned IO probably helps.

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

That is basically how clog passes the obtained Coda token to venus,
using a pioctl. Or did you mean the other way around where we could pull
the Coda (or some special one-time use) token back from venus and then
use that to authenticate that user over a unix domain or tcp (https?)
connection.

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

I agree.

> 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

Both unison and syncthing try to get all clients to store a complete
copy of all the data. I guess it is like Coda without the System:AnyUser
acl and an agressive hoard setup that always tries to cache everything,
never actually tried to use Coda that way. Ofcourse syncthing chunks up
a file in 128KB blocks and only sends modified ones so it will be more
efficient at propagating updates if only parts of a file change.

Jan