9P2000 is available on Linux with the CONFIG_9P_FS and related kernel compile options, which say things like:
"If you say Y here, you will get experimental support for Plan 9 resource sharing via the 9P2000 protocol. See http://v9fs.sf.net for more information."
It works in at least Ubuntu & Fedora out of the box, and is used by the virt-manager GUI to set up shares, so not too experimental to enable by default I guess.
On Arch Linux, it's been enabled by default for several years, and I've been using it daily for that time.
On x86_64, it's plenty stable, but I see why it's still experimental: On i686 there's a bug where files are mysteriously missing from directory listings. I tried to debug it once; it's reading them from the protocol correctly, but they're being dropped in the VFS layer, which is a bit more complicated than the network protocol.
9p is really easy to implement. That is a key feature as it makes it easy to create new clients and servers (and presumedly makes bugs rarer). Much like FUSE has been adapted to countless things. I don't know how implementing a FUSE server or client compares to this though.
Unfortunately, the simplicity also means giving up something. Where quite-complicated NFSv4 can be very efficient over slow links (leases makes it a bit like a cache coherency protocol), 9p requires all writes to be committed to the server (for coherency).
I was wondering how v9fs compares to vanilla filesystems like ext2... I suspect I'm comparing the wrong thing and it's a just a NFS-like protocol and not a on disk format? If so, what is the plan9 on-disk format?
I feel like I'm missing the point and should be asking "what's cool about 9p?" to which you provided a very helpful response. Thanks!
Which one? For most user storage, there's kenfs, fossil, venti, hjfs, cwfs, and a few others. But 9p is disjoint from where data is stored, it's just a protocol for doing RPCs on endpoints in a heirarchical namespace.
As a result, everything is served up over 9p on plan 9. iso9660, the device tree, the network subsystem, ftpfs, sshfs, hgwebfs, the vt100 emulator, the keyboard, the mouse, the CD burner commands, and so on. To a good approximation, the only things you can do without going over 9p is starting processes.
This has interesting implications; For example, the Plan 9 equivalent of ssh simply opens a connection to the remote system, and mounts the local /dev before the remote one. That means that remote programs simply open the local devices, such as the mouse and keyboard, and use them in preference to the devices that are connected to the remote machine.
Cool. Is that sh? I'm not familiar with the [1=2] stuff... looks like it's remapping file descriptors, is there something special about 10, 11 and 12? I can feel my weekend slipping away...
IIRC the native Plan9 FS is still something very similar to tradional unix filesystems, but it is intended to be replaced with Fossil (http://doc.cat-v.org/plan_9/4th_edition/papers/fossil/). It's copy on write filesystem (like ZFS or BtrFS, but it only implements the filesystem part) with interesting property that it supports cheap snapshots which can be offloaded into Venti, which is content addressable object store (similar to Git's internal object store)
If you were going to build a JSON based file system today, then I would study the Newton’s Soup which was based on frames. It was pretty cool and had some interesting capabilities (remove half the storage from a running system, ok what’s next). I would imagine queries would make a reappearance in a much nicer form.
Thats exactly what I thought. Newton Soups and NewtonScript were both awesome. I miss that kind of system these days, it still amazes me how it was all integrated.
"If you say Y here, you will get experimental support for Plan 9 resource sharing via the 9P2000 protocol. See http://v9fs.sf.net for more information."