Building a 64-bit 1TB SATA RAID file server with FreeBSD 6.0-amd64

This is an account of my varied experiences building aenea, a new server for my network whose primary feature is 1TB of SATA RAID5 storage. This experience was non-standard for a few reasons:

  • Case selection was nuanced
  • SuperMicro hot-swap drive cage was a hassle
  • Shogun heat sink was a total farce
  • Shogun heat sink almost obscures the PCI-Express slot
  • HP LiteScribe CD sucks
  • FreeBSD 6.0 doesn’t support the RocketRaid 2220
  • Figuring out how to mod the RR222x driver to 1) build on FreeBSD 6 and, 2) cross-compile for amd64 from i386
  • RR222x BIOS utility is shit; ‘background initialization’ means deferred initialization
  • Without the RR222x RAID management utility, only way to trigger volume init is writing to the file system; I did this by doing a FreeBSD install. Catch is, the install doesn’t actually happen (the volume isn’t initialized yet), and you must leave the box powered on for hours until the disk lights stop flashing, indicating the init it done. Then you can reboot and do a normal install.
  • Lack of floppy forced use of USB floppy drive, which is fine except it took the /dev/dc0 slot, making the array /dev/dc1, though it will be /dev/dc0 if the USB floppy isn’t present. Thus, have to unplug floppy after hptmv6.ko kernel module is loaded.
  • After install, copy hptmv6.ko to /boot/kernel and modify /boot/defaults/loader.conf by adding this line:
    hptmv6_load="YES"
    
  • Had to add
    interface "em0" {
        send host-name="aenaea";
    }
    

    to /etc/dhclient.conf, as FreeBSD is the only OS I’ve used that doesn’t automatically send its hostname to a DHCP server.

  • RAID management tools come only in 32-bit version. From the FreeBSD-amd64 list it seems you can get i386 compatibility if you build from source, which obviously I will do.
  • The array suddently went ‘Critical’ on me, with disk 3 (1-based) showing up as ‘Degraded’. Of course, no docs. Now the array is spinning like crazy; my hope is that it’s repairing the degraded disk. Without management tools, I can’t know. I’m wary of building from source with the array at Critical; not only will it be slow, but it can only prolong the recovery process.
  • Once the array got back to ‘Normal’, I ran a make buildworld, but the disk IO stalled during the build. It’s fairly clear that, due to amd64, version 6.0, or using FreeBSD, these volumes simply won’t work.

    I’ve no choice but to slink back to a mainstream OS. I’m leaning toward Fedora Core 4, even though it’s shit as a server system. The alternatives are Red Hat Enterprise Server (not an option) and SuSE Desktop Linux (as if FC4 wasn’t lame enough).

    The make buildworld has since unstuck itself; maybe if I can get a kernel and userland with i386 support, I can run the CLI management tools and I won’t be so screwed. We’ll see. It’ll take hours to download FC4 binaries anyway, so there’s no harm in trying.

UPDATE: this is rather agonizing. FreeBSD 6.0 release works, more or less. I can’t run the i386 CLI management tool, to no surprise. I created a few symlinks to shared libraries to get it to start, only to get this:

 Nov 25 18:06:20 aenea kernel: pid 699 (hptsvr-5.3), uid 0: exited on signal 11 (core dumped)

Not surprised; not only were these tools compiled for an earlier version of FBSD, but they’re running in the i386 compatibility layer.

The problem is there are little events that naw at me, making it impossible for me to delude myself into thinking the situation is tenable. For example, getting hung up during the buildworld. Also, doing a shutdown causes kernel panics during the unmount process.

I’m going to stress-test the disks a bit more with some port building, and see how that goes.

Tags: , , , ,

Leave a Reply