Damn, reading for exams is really not my favorite thing. It’s not that it’s very hard material, but the motivation is the problem. I always tend to get a bit sloppy with classes where the only form of assessment is the exam, and if the class is not very interesting either, it gets hard. However, these kind of classes are typically very theoretical courses, and one way I cope with it is to make them practical. For instance, in this course there are lot of distributed algorithms that the student is expected to know. Some of them are almost several pages long, and I’m really not the type for keeping all that in my head, and if I did, it would only be because I memorized it. So instead, I tried to implement the algorithm, as it helps with understanding because you can see how it works in action! What I did in this case was to create a node abstraction/class which I could re-use in several algorithms. The nodes definition is something like this:

void send(Message, nodeid);	// Send message to a single node
void multicast(Message);	// Multicast message to all neighbouring nodes
void deliver(Message);		// RMI method called by other nodes via their send method
Message receive();		// Blocking receive method to fetch contents from buffer

The node creation itself adds necessary neighbours, and connections are specified at startup time. The Message class contains most info necessary, but is extended in some algorithms that need extra stuff. I implemented these algorithms using the interface:

• Ricart-Agrawala’s mutex algorithm
• Maekawas mutex algorithm
• Peterson election in unidirectional ring

Some algorithms are really tricky, and I end up spending more time wondering how to implement it than actually doing it, so I guess this technique is not good always :)

Phew, the first quarter of my exchange study is almost over. So far, the stay here in the Netherlands have been very exciting. First of all, we did an awesome project creating a quad rotor controller using a joystick to fly. A demo of the previous years group can be found here. We were actually able to make it work like in this video. The hardware consists of a Xilinx Spartan 3E starter kit running the X32 CPU core developed here at TU-Delft, a PC with serial link to the FPGA board, a joystick connected to the PC, and the Quad Rotor itself connected to the FPGA board via a modified serial link. We implemented the control software, signal filtering etc on the X32 in C, and after optimizations, we had a cycle time almost half of the required, and it flew!

The other course I’ve been taking is a seminar on wireless sensor network, which handled nearly all aspects of this topic, having students present a paper on a certain topic each week. I presented a paper on reliable energy aware routing, which was very interesting.

Lastly, I have a course in distributed algorithms, which will finish on April the 4th with an exam. The course teaches various distributed algorithms for synchronization, global state detection, deadlock, locking etc, and goes through several P2P protocols as well.

After this quarter I’ll also go home to Norway for a short vacation, finally :)

After loader support for ZFS was imported into FreeBSD around a month ago, I’ve been thinking of installing a ZFS-only system on my laptop. I also decided to try out using the GPT layout instead of using disklabels etc.

The first thing I started with was to grab a snapshot of FreeBSD CURRENT. However, I discovered that the loader doesn’t support ZFS, so you have to build your own FreeBSD cd in order to install a working loader! Look in src/release/Makefile and src/release/i386/mkisoimages.sh for how to do this. Since sysinstall doesn’t support setting up ZFS etc, it can’t be used, so one have to use the Fixit environment on the FreeBSD install cd to set it up. I started out by removing the existing partition table on the disk (just writing zeros to the start of the disk will do).

Then, the next step was to setup the GPT with the partitions that I wanted to have. Using gpt in FreeBSD, one should create one partition to contain the initial gptzfsboot loader. In addition, I wanted a swap partition, as well as a partition to use for a zpool for the whole system.

To setup the GPT, I used gpart(8) and looked at examples from the man-page. The first thing to do is to setup the GPT partition scheme, first by creating the partition table, and then add the appropriate partitions.

gpart create -s GPT ad4
gpart add -b 34 -s 128 -t freebsd-boot ad4
gpart add -b 162 -s 5242880 -t freebsd-swap ad4
gpart add -b 5243042 -s 125829120 -t freebsd-zfs ad4
gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ad4

This creates the initial GPT, and adds three partitions. The first partition contains the gptzfsboot loader which is able to recognize and load the loader from a zfs partition. The second partition is the swap partition (I used 2.5 GB for swap in this case). The third partition is the partition containing the zpool (60GB). Sizes and offsets are specified in sectors (1 sector is typically 512 bytes). The last command puts the needed bootcode into ad4p1 (freebsd-boot).

Having setup the partitions, the hardest part should be done. As we are in the fixit environment, we can now create the zpool as well.

zpool create data /dev/ad4p3

The zpool should now be up and running. I then decided to create the different filesystems i wanted to have in this pool. I created /usr, /home and /var (I use tmpfs for /tmp).

Then, freebsd must be installed on the system. I did this by copying all folders from /dist in the fixit environment into the zpool. In addition, the /dev folder have to be created. For better details on this, you can follow (http://wiki.freebsd.org/AppleMacbook) At least /dist/boot should be copied in order to be able to boot.

Then, the boot have to be setup. First, boot/loader.conf have to contain:

zfs_load="YES"
vfs.root.mountfrom="zfs:data"

Any additional filesystems or swap has to be entered into etc/fstab, in my case:

/dev/ad4p2 none swap sw 0 0

I also entered the following into etc/rc.conf

zfs_enable="YES"

In addition, boot/zfs/zpool.cache has to exist in order to be able to let the zpool be imported automatically when zfs loads on system boot. To do this, I had to:

mkdir /boot/zfs
zpool export data && zpool import data

In order to make /boot/zfs/zpool.cache get populated in the Fixit environment. Then, I copied zpool.cache to boot/zfs on the zpool:

cp /boot/zfs/zpool.cache /data/boot/zfs

Finally, a basic system should be installed.The last ting to do is to unmount the filesystem(s) and set a few properties:

zfs set mountpoint=legacy data
zfs set mountpoint=/usr data/usr
zfs set mountpoint=/var data/var
zfs set mountpoint=/home data/home
zpool set bootfs=data data

To get all the quirks right, such as permissions etc, you should to a real install with making world or using sysinstall when booted into the system. Reboot, and you might be as lucky as me and boot into your ZFS-only system :) For further information, take a look at:

http://wiki.freebsd.org/ZFSOnRoot which contains some information on how to use ZFS as root, but by booting from ufs and: http://wiki.freebsd.org/AppleMacbook which has a nice section on setting up the zpool in a Fixit environment.

Update:

When rebuilding FreeBSD after this type of install, it’s also important that you build with LOADER_ZFS_SUPPORT=YES in order for the loader to be able to read zpools.

Finally, I have been able to resolve all current known issues with cvsmode support in csup. I just sent out a new announcement with the patch, and I hope to get some more testing and perhaps some reviews soon, but it is a big patch and few people are familiar with the code base.

Remaining issues with the patch is support for using the status file when reading (but this is not critical at all), as well as rsync support (which is only significant for a few files in the freebsd repository).

I hope as many as possible are able to test it:

http://people.freebsd.org/~lulf/patches/csup/csup_09_16_2008.diff

The last couple of weeks I’ve been very busy with school (and I expected this to be a quiet semester). However, I’ve found some of the last few bugs lurking around in csup:

• Deltas that had a 'hand-hacked' date would have deltatexts that would be misplaced in the rcsfile.
• When adding a new diff, a '..' would be converted to '.' twice, meaning it disappeared.

Now, there are only these issues left, but I’m not sure if I really want to fix this:

• Some RCS files have an extra space between desc and the deltas. CVSup fixes this by _counting_ the lines and then write them out when writing out the RCS file. I think this is silly, since it doesn't really matter according to the RCS standard.
• Some files appear to display garbage values, such as src/share/examples/kld/firmware/fwimage/firmware.img,v This disappears for some reasons in csup, but I'm not sure how to handle this. Comments are welcome.
• It has a quite high memory usage, and this might be due to some leaks that I've been unable to find. I'll do a much better audit of the code and run valgrind to investigate this further.
• Does not support md5 of RCS stream, so it can't detect errors yet.
• Statusfile file attributes might not be correct.
• Some RCS parts such as newphrases (man rcsfile) is not supported yet.
• Some hardcoded limits that may break it.
• Things done a silly way such as sorting and comparing, which I have plans to improve later.

So, finally, you can try out patches if you’d like: http://people.freebsd.org/~lulf/patches/csup/cvsmode

Currently, I’m including the tokenizer generated by flex, since the flex file itself can’t be compiled with csup.