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.
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).
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/srcto 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.