9PFS

Experimental Plan9 file system support

This is an experimental mode for the Coda client to (eventually) allow interacting with the Coda file system without requiring a Coda specific kernel module. There are several reasons this may be of interest.

1. The Coda kernel module is not always built for default distribution kernels, and with locked down systems with secure boot and signed kernel modules it may not always be easy (or possible) to build and load your own Coda kernel module.
2. There are Operating Systems that do not have a Coda kernel module, or an existing Coda kernel module may be broken for several reasons (VFS api or locking changes, bugs uncovered by stricter bounds checks, etc)
3. Reduce maintenance burden on VFS maintainers. I'm not saying I want the Coda kernel module excised from the various kernels that support us, but we are doing some things like swapping inode->i_mapping around in Linux that aside from Coda doesn't seem to be used very much.

So why not try to see how far we can get by leveraging an existing file system. At first we started to look at the obvious solution, FUSE. But once everything is said and done we'd need a helper process that handles the upcalls from FUSE and then passes them on to the Coda client. But while looking at what protocol to use between the FUSE helper and the Coda client I found that 9pfs has a simple, yet potentially complete enough, protocol that has at least one or more FUSE based client implementations, a Linux v9fs kernel module, and several user space libraries and tools. And if we fail to get a portable solution, it shouldn't be too hard to extend the protocol for any missing bits.

The current implementation is highly experimental and will allow anyone with access to the mariner socket to impersonate you and access your most private files in Coda. And by default any local user can access the mariner socket because codacon uses it.

Right now we've been working towards a somewhat reliable support for the plain '9P2000' protocol. There are no symlinks or ioctls so we cannot represent dangling mountpoints, discovered conflicts, or interact with the Coda file system client using clog, repair or cfs commands. As such we still need to mount the usual /coda mount with the existing Coda kernel module, but a user can now optionally mount a new 'view' of the Coda file system anywhere under his/her home directory.

Example usage:

$ # start the Coda client with an extra -9pfs flag, i.e. venus -9pfs
$ mkdir -p ~/test
$ 9mount -i 'unix!/run/coda-client.mariner' ~/test
$ ls ~/test/testserver.coda.cs.cmu.edu/
$ 9umount ~/test