Last week my company sold old hardware for a bargain price. I got one, a dull Dell machine self-named “Optiplex GX 260”. It gained a place in my home next to Albert — my plant — and also a new name: “fungus”.

Fungus was the occasion to refresh my experience with FreeBSD. I have very fond memories of this operating system, which I used in the past for network services; this week, I wanted to extend my knowledge of the system by trying out the new features and checking its compatibility with various pieces of hardware which prove burdensome to use with Vodka-Pomme, my iBook.

Suffice to say, I am not too proud with the results.

It did begin quite well. Well, not that well. The system fails to boot with the default settings, due to a faulty hardware feature (broken ACPI) which is not (yet) worked around by software. Only some research brought me the magic string required to move to the next step: hint.apic.0.disabled=1

Damn the bogus Dell hardware.

For the installation I used the April snapshot of the 7.0-CURRENT branch, the brand new stuff scheduled to be released later this year. My purpose in using the latest and greatest (and I had to expect, also unstable) was to benefit from the recent inclusion of the ZFS filesystem into FreeBSD.

Installation went smoothly, and I could perform the following operations with much success and pleasure — pleasure to feel in known territory, pleasure to discover the changes since the last time I used the same steps:

• load updated system sources from CVS
• rebuild and install the world and a custom kernel
• install some shells and utilities
• configure some networking and connect to IPv6

Everything went smoothly so far and I could nearly believe that I was on the road to success for all my plans with Fungus: file server, webcam controller, ip6 gateway, scanner controller, and maybe some more! Spare time allowing, of course.

Before going to work last morning, I plugged in the USB flatbed scanner — CanoScan Lide 500F, based on chipset GL841 — and decided to give a try at SANE using a remote access to Fungus during the day.

It turned out that:

1. the scanner is not supported by SANE (bad)
2. it disconnects itself from the USB bus when it receives data it does not like from the driver (good)
3. my first attempt at hacking some SANE parameters to forcibly attach the closest matching driver (sane-genesys) to the scanner caused the scanner to disconnect (bad, I was 10km away)
4. my second attempt (back home in the evening) involved actually changing the source code of the driver to extend its compatibility to the model of my scanner. It was met with the scanner disconnecting again (bad) and a kernel panic. (doubleplus bad bad)

No amount of quick-‘n-dirty hacking would avoid me doing the work of the developers of sane-genesys. Since I did not have either time nor knowledge to proceed, I decided that my scanner would keep its place somewhere next to Vodka-Pomme.

Next attempt was plugging in an USB Creative WebCam which I sometime use to capture short movies or interact visually with friends over the internet.

It turned out that:

1. there is no infrastructure for video capture on FreeBSD, like V4L on Linux - therefore, no standard driver interface (kinda bad, mostly inconvenient since no generic capture program is thus available)
2. the only existing driver, a port from the Linux driver using a system glue adapter, does not compile out of the box — I had to manually tweak the sources to workaround some incompatible definitions of the system call “msleep” (some time wasted, bad)
3. the driver triggers a storm of kernel messages upon load (bad)
4. no data is actually returned by the driver upon request of a picture from the camera (very bad)
5. unloading the driver after the tests causes a very verbose kernel panic (doubleplus bad bad)

At this point I decided that my webcam would also keep its place somewhere next to Vodka-Pomme, and I abandoned any hope of using FreeBSD for multimedia purposes.

It was therefore obvious that I should focus back on my main project, which was setting up a file server.

That was easier said than done. Most of the data I want to serve is stored on two mirrored hard disks connected via USB. My primary goal is ensuring redundancy at all times, so that loss of one disk does not cause loss of all the data (sorry for stating the obvious). The secondary goal is to be able to take away one of the disk at any time to access the data using a different computer if needed, and still be able to plug it back into the main system afterwards and synchronize with the first disk. This later “feature” seems simple enough to me, and this is already what I am doing with the software RAID driver of MacOS X.

For this purpose, four different mirroring systems as available on FreeBSD:

• the plain CCD driver, quite simple and basic
• GEOM vinum, “traditional” way of doing things
• GEOM mirrors (gmirror), the recommended way with FreeBSD 5 and later
• ZFS mirrors, the latest and greatest.

All four work quite well and are (in my opinion) fairly easy to implement, although I am not yet sure whether I want to go for ZFS or if gmirror is good enough for me…

At this point my primary goal was within reach with no hassle, and I could focus more seriously on the secondary goal, the ability to take one disk away while the system is running.

Interestingly enough, it works quite well if you instruct the system to “say goodbye” to the disk before it is unplugged, by means of “unmount”, “gmirror detach”, “zpool detach” and so on. However, that is too much of a hassle. The point of USB is precisely to be able to unplug devices and expecting the system to recover gracefully whenever possible — and disk mirroring should make this possible if the other disk is left plugged.

Unfortunately my tests exposed the final blow to my efforts: FreeBSD cannot deal with disconnects of USB mass storage devices while the devices are in use. “The full fix will require a fair amount of rearchitecting.” Yeah, right, I don’t really have that time to wait.

Now, I’ll let Fungus rest in peace for a while, and I’ll try reviving it later and see what good can come out of it. If none, I’ll go for OpenSolaris instead.