Plan 9 Network at Home

Here is a summary of my home Plan 9 network, running the Fourth Edition of Plan 9. The Plan 9 network at work is similar in structure although the hardware details differ.


A set of Netgear 1G/bit switches provides the underlying network for servers, and a Netgear WNDR3700 using DD-WRT firmware provides the 802.11bgn wireless network for laptops and portable devices. All Plan 9 machines effortlessly and simply share a single file store on the network, provided by the single file server dispensa; most Plan 9 machines either haven't got discs or don't use them for ordinary file storage. The system is connected through a NAT box to the Internet by a Virgin Media cable modem (120Mbps). (It has got an RJ45 ethernet connection and uses DHCP to set the NAT box address.) The NAT box redirects most services to the Plan 9 CPU server. It receives incoming calls in the usual Plan 9 way, via aux/listen. A few specialised services are redirected to other machines.

Having a single file store with just one copy of the system software simplifies maintenance, reduces copying, and keeps the clients simple, cheap, and quiet(er). I simply plug in a new machine, make an entry in /lib/ndb/local, and boot. Discless PCs load the boot program 9load from a flash drive or small SSD, then load the kernel from the cpu server over the ether (eg, using PXE boot for Intel). The notebook machines use a file system on local disc when running detached, but connect to the shared file system when connected to home or work networks, though still allowing access to their local disc. They use DHCP to select the correct Internet address for the network to which they are connected (eg, home or work).

File store

A Plan 9 file server provides the primary shared file storage over the Ether network to both terminals and CPU servers. The file server runs a specially-configured cpu kernel that does nothing but serve files over the network and run the authentication services. Plan 9 provides an automated backup system known as the dump file system. That previously was done by a special kernel; now it is done by a combination of a block archiving service (venti), and a file archiving service (fossil) that stores its data in venti. The entire file store is kept on banks of cheap discs, perhaps arranged in a RAID configuration, and its copy-on-write characteristic is turned to advantage: at 5am each morning the file server automatically saves the a pointer to the root of the existing hierarchy, and creates a new root pointer for further updates, which are made copy-on-write (including directory updates). The file server exports a dump directory, typically mounted on /n/dump, containing names of the form yyyy/mmdd, each providing a snapshot of the entire file store on the given date. Amongst other things, this allows running commands such as

diff -r /n/dump/2002/0101/sys/src /sys/src
to see what has changed in the sources since the start of the year, or yesterday(1):
yesterday -d .
to see whether a change I made in the current directory yesterday might explain a bug today. Using Plan 9's bind primitive, parts of the dump can be bound over parts of the current hierarchy (eg, for regression testing). Archival snapshots are typically made once per day, but intermediate snapshots can be made much more often (I do them hourly). The difference is that archival snapshots are written to venti in immutable storage; intermediate snapshots and updates between them are made in a rewritable area on disc.

This is a cheap way to get the automatic source and object file control and auditing provided by the dump file system.


The machines on the network are a mixture of Intel and ARM (eg, Raspberry PI), most now are low-power. I assemble the PC servers myself from components. The servers and network components are on a cheap Belkin UPS.
1 February 2015