I am writing to bring up the notion of FUSE again.

Currently, one has to have a kernel module just for coda.  This used to
be the only way it could have been done, but is now boutique.  If every
filesystem needed its own special module, the overall situation would be
untenable.  Given coda's small user base, this module is a maintenace
burden on operating systems.  NetBSD has just discussed whether to
remove coda kernel support, as it has almost no users.  For now, it is
staying.

Now, almost all filesystems that have user-space implementations --
perhaps everything but coda -- use FUSE, most the high-level API, and a
few (glusterfs) the low-level API.  On NetBSD, glusterfs has been
observed to have good performance via this path.

I realize there are two perceived issues.  One issue is an efficiency
concern, but I feel that basic functionality and portability is being
sacrificed for efficiency, and a filesystem I can't run everywhere
effectively has zero performance because it doesn't meet basic
requirements and thus can't be used.  However, supporting FUSE, and not
having the kernel module work are separate issues, and it's entirely
possible to have a FUSE method that is portable and a kernel module that
is perhaps somewhat faster.

The second issue is about pioctl and the extra signaling path, but I see
no reason that can't work with magic filenames and ioctl.

Given how coda is implemented, I expect that FUSE support is not that
hard, and is almost entirely about a new data path for pioctl and having
user-space code implement read/write ops for container files, now
short-circuited.

Without FUSE, I think coda will continue to exist in the margins and has
no real hope of mainstream use.  Certainly I am unlikely to start using
it again in this state.   So I ask that you consider FUSE support as an
important priority.