The ubiquitous fs in Plan9

The terms file server, file system and the abbreviation fs appear a lot in Plan9 documentation. For example, there are the manpages fs(3), fs(4), fs(8), and kfs(4).

First fs(4) aka Ken's FS. This was a file server inside the kernel which required a specially built kernel and was used together with a dedicated CPU server and many terminals. It is not part of the kernel sources any more, but its manpage lives on. To add confusion, there is also a manpage fs(8) for the console of Ken's fs.

Then there is kfs(4), a file system for terminals. It is implemented in user-space. No relation to Ken's FS besides the name. Strangely there seems to be no option to repair a broken kfs:

If the file system is inconsistent, the user is asked for permission to ream (q.v.) the disk.

(reaming means deleting). kfs cannot be managed by a console like Ken's fs and fossil, but by options to an executable kfscmd. UPDATE kfscmd has commands to repair a broken kfs.

As another example for the non-injectivity of abbreviations, there's fs(3) which is not a file system at all, but a kind of soft-raid that allows concatenation, striping and (simple) mirroring of files, e.g. disks.

On the fourth hand, there is fossil. This is the current default for CPU and File servers. It can be configured to move its blocks to an archival storage server venti. It is managed with its own console fossilcons which attaches itself not as /srv/fossilcons but /srv/fscons.

[/plan9] permanent link

Plan9

Plan9 is an operating system by the authors of the original Unix, with integrated support for distributed applications.

Plan9 has its own windowing system, rio, quite different from X11.

It is possible to connect to Plan9 machines by drawterm from Unix machines running X11. drawterm starts the windowing system on the remote Plan9 and everything works as if sitting in front of it.

While typing from one machine I remembered I had already solved a problem in a one-liner, but on a different drawterm which ran on a Unix box miles away.

cpu% echo $wsys
/srv/rio.myname.1234
cpu% lc /srv/rio.*
rio.myname.1234		rio.myname.5678

So the other drawterm runs the rio mounted on /srv/rio.myname.5678. To get at the scrollback of a window displayed on a screen on a totally different machine:

cpu% mount /srv/rio.myname.5678 /n/wsys 1
cpu% cat /n/wsys/text 
[...lines of output...]
[...including the one-liner...]

[/plan9] permanent link