csant/log

Ever since I moved from the standard SUSE 9.3 kernel 2.6.11 to a custom built 2.6.14, upgrading was a joy: the first step on an upgrade to a minor version bump takes a while: it is a minor version increase, yet support for tons of new drivers and configuration options are added, you walk your way through the configuration, make and then make modules_install && make install - and ready you are.

When we talk versioning number, it is interesting to note that with the A.B.C[.D] scheme, or <version>.<major>.<minor>[.<patch>] scheme, a D number first occurred when a grave error, which required immediate fixing, was encountered in 2.6.8's NFS code - today D numbers are released every other day…

It was a joy, I said - until the upgrade came from 2.6.19 to 2.6.20. It took me a few days to fix some issues with proper loading of some modules, certainly due to an older udev I am using. I solved it by finally deciding to compile those modules into the kernel (fair enough, why didn't I do that earlier?).

And then came 2.6.21 - somebody even saw some connection to the disaster of the Chernobyl Nuclear Power Plant… It was followed by a patch release a few days later with two bugfixes for networking issues that should cause all users of ipv4 or ipv6 to upgrade to this version. Right. IPV4: Fix OOPS'er added to netlink fib. 2.6.21 died every half an hour on my machine.

Following this much less pleasant release, there was a long and interesting debate on the LKML about releasing with known regressions.

0 regressions is never realistic (especially since many regressions
might not be reported during -rc), but IMHO we could do much better than
what happened in 2.6.20 and 2.6.21.

No kidding. The quality is really going down the drain - and this, notabene, is said by somebody who is certainly not stress-testing or cornering the kernel into odd cases. I am kernel's Joe Average who is just using his machine to accomplish some other tasks. I am fine with putting up with a few inconveniences, I know that can happen when you run "the latest" - but please, this is not the bleeding edge: I am not fond of running the bleeding edge development kernel! This is the latest stable version of the Linux kernel… Or rather: wannabe stable.

I have been running Plan 9 on one of my machines since February - first on-and-off from the CD, later giving it a more permanent dwelling on one of the disks.

Obviously I want to access the machine from other machines on the network - and since Linux supports the 9p filesystem in the main-line kernel since 2.6.14, it was extremely easy to set up.

Glenda

The first step is to set up the Plan 9 machine to allow a connection to its filesystem - the easiest way of doing so is to tell the fossil filesystem itself to listen to incoming connections:

term% con /srv/fscons
prompt: listen -N tcp!*!564
prompt: listen -N il!*!17008
prompt:

The right-most argument to listen is in the form net!host!service: basically we told fossil to listen on port 564 to any host, speaking the tcp protocol, and on port 17008 speaking the il protocol. The -N option tells the filesystem that an un-authenticated user may connect at any time (else he would be only allowed to connect from a certain machine after an authenticated user has connected) - keep in mind that you should use this only in secure environments - obviously you can be more restrictive with the IP address allowed to connect, and remove the -N flag to require authentication. That's about everything we need to do on the Plan 9 machine.

Tux

Next we switch back to the Linux system. Make sure you are running with support for 9p - enable CONFIG_9P_FS=m in the kernel .config file. (Note: the former 9p2000 module goes now under the name of 9p). You will also need the plan9port tools installed.

Start the factotum and the network file service:

$ factotum
$ srv plan_9_machine_ip

and then mount the Plan 9 machine:

$ sudo mount -t 9p -o proto=tcp plan_9_machine_ip /mnt/9/

That's all. Enjoy!

Note for the curious:

…or the uninformed: Tux and Glenda are, respectively, the Linux and Plan 9 mascottes.

…to your Linux box.

v9fs, the 9P file system support for Unix/Linux/*BSD, has entered the main Linux kernel tree as per version 2.6.13. 9P is the resource sharing protocol developed originally for Plan 9. It presents a unified distributed resource sharing protocol that will be able to distribute devices, file systems, system services, and application interfaces. It was revised for the 4th edition of Plan 9 under the name 9P2000.

The operating system Inferno is based on Plan 9, but both the original and the derivative product do not have a broad audience. Implementing the underlaying key concept on other UNIXes seems to be a very promising project, though, and likely to meet a much broader audience.

Setting it up on my Linux box was not too difficult. Here a little HowTo.

Setting it up

Step 1: enabling the client in the kernel

1. Grab a recent kernel source - I myself used a vanilla 2.6.15.4;
2. Enable CONFIG_9P_FS=m in the kernel .config file - unless you don't want it built as a module and need it directly in the kernel;
3. make and install your kernel as usual;
4. load your new module with `modprobe 9p2000`.

Step 2: installing the server

1. Download the UNIX 9P server, aka u9fs - there is ongoing work to implement the server into the kernel module as well;
2. make the server, and then
3. copy the binary executable to /usr/sbin/u9fs; you might also want to copy the file u9fs.8 in your source code directory to /usr/share/man/man8/ and read `man u9fs`;
4. one way to start the server is via xinetd - add the following to a new /etc/xinetd.d/u9fs file:

   service u9fs
   {
        disable         = no
        socket_type     = stream
        wait            = no
        user            = root
        group           = root
        protocol        = tcp
        port            = 564
        server          = /usr/sbin/u9fs
        server_args     = -m 65560
   }

5. and the follwing to your /etc/services:

   u9fs     564/tcp       9fs  # Plan 9 fs

6. there are three ways for authentication, none, the default rhosts and p9any; use rhosts only on very safe and controlled networks; none obviously turns off authentication altogether. Personally, I have not yet managed to get p9any working - so I have, for the time being (my network is safe), added the hosts of my internal network to /etc/hosts.equiv;
7. now `/etc/init.d/xinetd restart`.

Step 3: get it going!

1. `mkdir /mnt/9`
2. `mount -t 9P 10.0.0.1 /mnt/9` - make sure you replace the IP address with your own address; a warning: do not use a hostname, but a numeric IP address, the DNS lookup has been biased to work with NFS, but not with other distributed filesystems.
4. `ls /mnt/9/`

There are other ways to start the server and mount the filesystem in userspace only, but this is still new ground to me. At the moment the security model is still rudimentary - a safer alternative is to tunnel through ssh and call your own instance of the u9fs.

This is all not very exciting as long as the machine with the server is the same the client is running on - but becomes far more interesting when you mount remote machines. Currently I have only been able to access the filesystem, and this only in read mode, but as far as I have understood accessing devices and process resources shouldn't be too far off. And at that point 9P will be unleashed to its full potential.

What is the big deal about it?

Quoting from the main paper [PDF] :

9P2000 support provides a nice alternative to NFS for distributing static files. It can be configured in such a way that users can export and mount their own file system resources. Its synchronous mode of operation and optional caching make it ideal for situations where the cache models and delayed writes of other file systems cause problems. Many utilities, such as CVS and various e-mail servers, discourage the use of NFS repositories due to concerns with data corruption resulting from bad cache behavior and lack of transaction semantics.

However, as mentioned several times before - distributed file service is not the only benefit of 9P2000. It can be used to share networking stacks and block and character devices between members of a 9P2000 cluster. It can be used to manipulate Linux synthetic file systems, such as /proc and /sys providing distributed control and management. It also can be used as an infrastructure to implement distributed applications.

Userspace applications

Unfortunately there are not many applications in userspace yet - the main collection being Russ Cox's Plan 9 from User Space, aka plan9port or p9p, a port of many Plan 9 programs from their native Plan 9 environment to Unix-like operating systems. My somewhat biased perspective cannot but smile when reading the `man web` page - a sample quotation:

web, wmail - handle web page, mail message for plumber

[…]

The supported browsers are Opera, Mozilla Firefox, Mozilla Firebird, and Mozilla.

wmii is a very interesting dynamic window manager based on 9P.

Plan 9 and 9P is a new universe to me; it might be worth exploring it more, and following development of the v9fs. Once we get so far as to really share resources on Linux as well, a huge step forward will be achieved. I am looking forward to it.

Oh, and did I mention that Glenda, the Plan 9 bunny, is really cute?

Update 1

Interestingly enough, as soon as I have started digging into this project, some significant changes get announced. The v9fs site moves to a new location and u9fs is going to be replaced by npfs, the Linux-based set of libraries and servers that soon will find distribution in various packages, to be pushed out to distros.