DistOS-2011W Plan 9
Plan 9 from Bell Labs
Introduction
Plan 9 from Bell Labs (here on referred to simply as Plan 9) is a Distributed Operating system created by the Computing Science Research Center of AT&T Bell Laboratories, Which was also the group that developed Unix, and the C programming language[2]. It was first released in 1993 to various universities, and given a full release to the general public in 1995[2]. The most unique and interesting aspect of Plan 9 is that it represents all system interfaces via the filesystem including things not normally treated as files, like networking and the user interface.[2] That is to say, everything can be treated like a file, and thus can have read and write operations preformed on it. You would for instance, write Data to the network as though it were a file, and another computer would read that data. It was designed to be used in a distributed capacity, with some central computers for computation, a File server and many terminals for access, all of which is treated as one large system.
This report will go through the various aspects of the Plan 9 operating system and it's Distributed Operating system properties. Plan 9 was envisioned with 3 primary goals in mind, and this report will go into detail on each. First, All resources of the system should be represented as files in the filesystem[2]. Second, Given Application view should see an entire system as belonging to a single coherent namespace.[2] This should be independent of whether or not a given resource is local or remotely accessed. Two given namespaces might not show the same data, but all the data a given application or system sees should be presented as one namespace. Finally, all communication should be done via a standard communication protocol, which is called 9P. This report will go over these three main concepts in addition to Plan 9 and it's distributed properties in general.
A Standard Plan 9 System
Before we go into the details of a Plan 9, lets go over what a standard Plan 9 system would look like. A standard Plan 9 system is composed of 3 major parts; File servers for storage, CPU servers for computation, and Terminals for access.[4] File Servers and CPU Servers are normally centralized machines with multiprocessing capacities and many concurrent network connections. They require many fast network connections between each other, for maximized computation efficiency and request handling.
Terminals are can be either local or remote, and connected to the primary cluster via something as simple as an ethernet cable or something more complex such as a connection over the internet.[4] Terminal users can choose how they wish to distribute their workload; a local user could do most basic computation him or herself and only use the CPU servers for more complex tasks as they would be able to quickly access files on the Fileserver. A remote user could choose to do most basic computations on the CPU server, as it would be able to quickly access the Fileservers sending only the completed task to the remote terminal. This can be done because Both Terminals and CPU servers run on the same Kernel, making it easy for a Terminal user to assign a task to either his own terminal or a remote Server.[4]
Why Make Plan 9?
At the time of Plan 9's creation, The primary means of computing was via large Timesharing computers, but was trending toward the use of locally managed personal workstations[6], which is clearly a trend that has continued on to the present. The UNIX system of the time was built for use on these large systems. It was rather poor at dealing with networking and graphical interfaces, as these weren't added in until well into UNIX's life cycle. It was difficult to have a large system of small UNIX machines hooked up in a network configuration to communicate with each other. [6] an early motto of the team building the system was “build a UNIX out of a lot of little systems, not a system out of a lot of little UNIXes.”[6] a Plan 9 system is a bunch of Terminals and Servers working as one choerent system.
Plan 9 was thought up as a means of having a centrally administered system built out of distributed cheap personal workstations. Work would be divided amongst different machines, with machines dedicated to serving files, computation, and cheap personal terminals for simple tasks and accessing the larger centralized file servers and CPU servers. Terminals themselves shouldn't be personal devices, a user should log into a terminal and have his or her own personal space recreated on that machine. [6]
Plan 9's 3 main concepts
This section will cover Plan 9's 3 basic concepts, which are the basis for the entire system. I chose to focus on their ideas and less on the exact nitty gritty of how things are being done, as many of these things would warrant, and have gotten multipage essays, papers and reports detailing exactly what is going on. Also on a more practical level, I'm probably not going to get a lot of personal benefit from being an expert on in intricacies of Plan 9, but knowing it's key concepts, which are used in other operating systems (such as Linux having processes under /proc) seems like a good idea. I'm also quite interested in the concept of using many machines as single entity which is one of the main things Plan 9 was built for.
System Objects as Files
The first concept is that all system Objects are presented as named files that can be manipulated like files; they can be written to and read from. Things like networking, the window system, processes, and so on can be treated like file systems. For example, processes are stored in /proc and can be navigated to as though they are files, even though a process isn't really a file. [5]
Why do this? It makes things easy to distribute. A file needs to conform to certain standards, it needs to be able to be usable by multiple different machines. Files have to obey certain rules and regulations regarding naming, access, security and so on. A standard file system of folders or directories is easily understood by even a general user of the system. This makes them ideal for a distributed network; having all parts of the system obey certain commonly understood rules means a given system that can implement these rules are a ready-made to be used in a distributed context.[6]
Name spaces
This whole process is facilitated by the the use of namespaces created by processes. A given process or user will create a view of the system, a namespace, to connect all the relevant resources together. A Namespace won't be a collection of disks or computers, but rather a single hierarchical view of the relevant parts of the system. Each process has it's own namespace, and 2 given namespaces being used by the same user need not be identical. [5] For example, a process that views certain types of files for editing would have a different name space then the process which handles mouse and keyboard I/O. [5]
9P
9P is the protocol around which much of Plan 9 is based. 9P is the network protocol for components of Plan 9 to communicate with each other, and is what the vast majority of communication on a Plan 9 network will be composed of.[5] The protocol is 17 basic messages, almost all relating to file manipulation and querying. The protocol communicates in files, not blocks, vaguely similar to the concept of an object store. You don't ask for thirty 612KB blocks on network hard disk A13, but rather navigate through the namespace, attach yourself to a given file, and then reading and writing to that file.[5]
9Ps 17 messages for communication show just how file oriented Plan 9 is. version makes sure to communicating devices are using the same version of 9P. To establish a connection to a given location there is auth and attach. The result of a successful connection is a “channel”, which gives the root of a server. clone can create a copy of the channel. flush can abort a message, and error sends a message telling you exactly what you'd expect it to. What's more interesting is the rest of the messages. walk is used to move from one file to another in the hierarchy. open and create are used to prepare a new or existing file ID for I/O. read and write do exactly as you would expect. clunk informs a file server that the current file isn't needed by whatever is using it, the File's ID can be “forgotten”. remove will remove a file from the fileserver, assuming the device accessing it had write access. Even if it doesn't the file will be “Clunked”. stat and wstat enquire about metadata relating to the file, such as it's name, length, the last time it was accessed, the files owner and so on. [5][7]
Experiences and Discussion
I am going to discuss my personal attempt to get a Plan 9 network up and running. I won't go into too much details, as a managed to fail spectacularly multiple times, and the actual network I wanted to set up didn't get past the theoretical stage, but there is still some stuff worth mentioning.
My original System would've been set up as such: My laptop, by far my most powerful computer, would've served as a CPU server, as being a mid range laptop from late 2010 not all that impressive in and of itself, it blows the next two computers in this system out of the water. The next Computer would have served as the file Server; it was a entry level desktop from 2003/4, with an Intel Celeron 240 Ghz CPU from 2004, 224 MB of DDR RAM and 37 GB of storage. The final Computer would have served as the terminal. It was from 2000, had a Pentium 3, 64 MB of RAM and 10 GB of RAM.
Following a couple of Guides[1][3], I managed to get the File Server PC to the point where I could log into the default user. This part of the process was surprisingly simple. Plan 9 guides you through the process, hand feeding you what commands to enter. It goes through standard Operating system procedure, no more complex then any other operating system install. You partition the disk with either a file system, called Fossil, or a File system plus an Archival dump server, called Venti. This was the File Server, so I went with the second option. It them prepares the disk, deciding how much memory goes to each section. I went with the default configuration, which gave the Archival dump most of the memory (~30 GB), some of it to the File system (~6 GB) and the rest was divided between things like a Swap partition and a various things needed to properly boot the system.
At this point it formats and mounts the file system, formats and mounts the Archival server, and copies over the Plan 9 distribution. Worth noting is instead of formatting the system, you can copy a distribution or a file system from the network - which seems useful in a distributed system. You could in theory copy another system's archive. It would seem that the system is already creating namespaces for itself based on the installation disk and any other computer it may be connected to. The installation finishes, and the system reboots. After logging into the default user, called Glenda, I realize I have a problem. The system can't enter into it's UI, and Apparently my videocard isn't supported. The text I'm supposed to type to start up the window system, called Rio, crashes the computer.
I decide to switch to virtual machines at this point, using Virtual Box. I repeat the above process, and I do end up getting the graphical interface. It's somewhat confusing, but you can definitely navigate around and see that everything appears to be, in fact, a file. The problem I have now is that Plan 9 doesn't seem think it's connected to anything, which severely limited my Network to one computer I couldn't use to do anything. I'll admit I go frustrated at this point and decided it wasn't worth figuring out what I needed to do to get Virtual Box and Plan 9 to play nice, as there were reports to be written.
I wish I could have gotten the network up and running, I wanted to see it up in action, distributing work and accessing files on servers as though they were on the terminal.
Conclusion
Plan 9 is a
References
[1]http://plan9.bell-labs.com/wiki/plan9/installation_instructions/
[2]http://plan9.bell-labs.com/wiki/plan9/faq/index.html
[3]http://lsub.org/who/nemo/9.intro.pdf
[4]http://plan9.bell-labs.com/sys/doc/net/net.html
[5]http://plan9.bell-labs.com/sys/doc/names.html
[6]http://plan9.bell-labs.com/sys/doc/9.html
[7]http://man.cat-v.org/plan_9/5/