codegen's Journal: The long saga of using Linux to teach an OS Course

Several years ago (Summer of 2002), I decided to move from using java threads to linux for the labs in my operating system course. The idea was (and still is) to give a more hands on approach to the labs. Previous years labs had done the standard producer/consumer problem in Java Treads, simulate scheduling algorithms, simulate VM replacement algorithms, etc.

The one problem is that the labs at my university were mostly windows based, and even if they were linux based, the students would have to have root access to install modules. The other problem was server disk space. If this was to work, each student would have to have thier own virtual disk (minimum 500M perstudent). The upgrades to the main lab servers were not in the budget. The servers were from a commercial vendor and the proprietary disks were much too expensive on a per gigabyte basis. After pricing both vmware and connectix virtual PC (now owned by Microsoft) for bulk academic purchases, We obtained some curriculum development money and purchased:

1. Two Dedicated Servers for the class(1 GHz PIII, Raid 5 cards, Windows 2000 Server, 5 40 GB Drives). While I would have prefered Linux and Samba (More on that latere). I was not the one maintaining the servers, nor did I want to be. I have enough to do with teaching the class, managing TAs and Marking Exams. (As well as trying to keep up on my own research). The techs installing and maintaining the servers prefered windows.
2. 40 copies of Virtual PC for the machines in the Lab.
3. Funding for a 3rd year student for the summer to evalutate the approach (before Servers and Licences were prurchased) work out the bugs, and prepare two years worth of labs for the class. Some of the labs contained code skeletons to guide the students in writing the code. That is, files with some of the boilerplate code such as proc structures or device file operation structures already in place. This would allow the students to focus on the purpose of the lab and not get bogged down in some of the nuts and bolts to make it happen.

The evalutation went well. We used Red Hat 6.2 (older kernel) and were able to come up with 10 labs that would be suitable for a 3rd year OS class. Two of the reasons for using an older kernel was that that we could build smaller virtual disks (500M) and the kernel modules were simpler to write. The assignments ranged from introductory modules that created /proc files that read the clock, to more sophisticated modules that report on scheduling or virtual memory management within the kernel to a software device driver that managed kernel data queues (essentially a kernel pipe).

Based on the evaluation we decided to go ahead with the project. The servers were bought and installed. A base Virtual HD image containing the skeleton file was generated and copied out to all of the accounts. Tests were run and the first lab approached (Fall 2002). The student who work on the labs over the summer agreed to stay on as the TA during his 4th year studies.

Disaster. With only a couple of techs and one professor and one student, several tests had been run, but only a limited number of clients were run at a time (about 10). We had 40 machines on the lab, with 2 servers, means 20 machines per server. It turns out an individual server could not handle the load of 20 virtual machines booting at once. Once the VMs were up and running, network traffic was low enough that there were no problems, but 20 machines booting at once was apparently too much for the network and server. About 2 of the VMs would corrupt the virtual disks under the load. This was totally at random and different machines would do it each time. Needless to say this was a bit of a shock to the students starting up the VMs (as well as to the instructor[me]). For the 4 students affected (2 per server) we quickly copied new VMs into their accounts and had them boot up again.

to be continued...