started as Ken
Thompson and Rob Pike's attempt to address a number of perceived
shortcomings in the Unix model. Among other things, Plan 9 takes the
"everything is a file" approach rather further than Unix does, and tries to
do so in a distributed manner. Plan 9 never took off the way Unix
did, but it remains an interesting project; it has been free software since
One of the core components of Plan 9 is the 9P filesystem. 9P is a
networked filesystem, somewhat equivalent to NFS or CIFS, but with its own
particular approach. 9P is not as much a way of sharing files as a
protocol definition aimed at the sharing of resources in a networked
environment. There is a draft
RFC available which describes this protocol in detail.
The protocol is intentionally simple. It works in a connection-oriented,
single-user mode, much like CIFS; each user on a Plan 9 system is
expected to make one or more connections to the server(s) of interest.
Plan 9 operates with per-user namespaces by design, so each user ends
up with a unique view of the network. There is a small set of operations
supported by 9P servers; a client can create file descriptors, use them to
navigate around the filesystem, read and write files, create, rename and
delete files, and close things down; that's about it.
The protocol is intentionally independent of the underlying transport
mechanism. Typically, a TCP connection is used, but that is not required.
A 9P client can, with a proper implementation, communicate with a server
over named pipes, zero-copy memory transports, RDMA, RFC1149 avian links,
etc. The protocol also puts most of the intelligence on the server side;
clients, for example, perform no caching of data. An implication of all
these choices is that there is no real reason why 9P servers have to be
exporting filesystems at all. A server can just as easily offer a virtual
filesystem (along the lines of /proc or sysfs), transparent remote
access to devices, connections to remote processes, or just about anything
else. The 9P protocol is the implementation of the "everything really is a
file" concept. It could thus be used in a similar way as the filesystems
in user space (FUSE) mechanism currently being considered for merging.
9P also holds potential as a way of sharing resources between virtualized
systems running on the same host.
There is a 9P implementation for Linux, called "v9fs"; Eric Van Hensbergen
has recently posted a v9fs patch set for
review with an eye toward eventual inclusion. v9fs is a full 9P client
implementation; there is also a user-space server available via the v9fs web site.
Linux and Plan 9 have different ideas of how a filesystem should work, so a
fair amount of impedance matching is required. Unix-like systems prefer
filesystems to be mounted in a global namespace for all users, while
Plan 9 filesystems are a per-user resource. A v9fs filesystem can be
used in either mode, though the most natural way is to use Linux namespaces
to allow each user to set up independently authenticated connections. The
lack of client-side caching does not mix well with the Linux VFS, which
wants to cache heavily. The current v9fs implementation disables all of
this caching. In some areas, especially write performance, this lack of
caching makes itself felt. In others, however, v9fs claims better
performance than NFS as a result of its simpler protocol. Plan 9 also
lacks certain Unix concepts - such as symbolic links. To ease
interoperability with Unix systems, a set of protocol
extensions has been provided; v9fs uses those extensions where
The current release is described as "reasonably stable." The basic set of
file operations has been implemented, with the exception of
mmap(), which is hard to do in a way which does not pose the risk
of system deadlocks. Future plans include "a more complete security
model" and some thought toward implementing limited client-side caching,
perhaps by using the CacheFS layer.
See the patch introduction for pointers to
more information, mailing lists, etc.
to post comments)