A filesystem from Plan 9 space
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 indicated.
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.
Index entries for this article | |
---|---|
Kernel | Filesystems |
Kernel | Plan 9 |
Kernel | v9fs |
Posted Jun 6, 2005 16:53 UTC (Mon)
by stfn (guest, #30357)
[Link]
That might be a naive simplification* but other have observed the same:
http://www.xent.com/pipermail/fork/2001-August/002801.html
* It's only one aspect of the design and, on the other hand, there's all kinds of caching in the web and URIs if not URLs are meant to form a global namespace that all users share.
Posted Jan 13, 2006 16:46 UTC (Fri)
by nealmcb (guest, #20740)
[Link]
Terminology is pretty important when it comes to IETF documents, and the word "Draft" can lead to confusion.
"This document is an Internet-Draft and is NOT offered in accordance with Section 10 of RFC 2026, and the author does not provide the IETF with any rights other than to publish as an Internet-Draft."
I've never seen anything like that - why publish an internet draft that states up front that you aren't playing by the rules and you don't want to procede?
The design philosophy shares something with the recently popular "REpresentational State Transfer" style of web services. They each chose one unifying metaphor and a minimal interface: either everything is a file and accessed through file system calls, or everything is a resource and accessed through HTTP methods on a URL.REST for the web is a bit like that
http://rest.blueoxen.net/cgi-bin/wiki.pl?RestArchitectura...
"There is a draft RFC available which describes this protocol in detail."Not ever an RFC, not even an internet draft
No, there is no Plan 9 RFC, it doesn't look like there will be one, and there certainly is not an RFC that has advanced to the "Draft Standard" phase. There is not even an "Internet Draft" any more, since it expired. And the Internet Draft that was submitted explicitely stated that