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)
