Dominic Cleal's Blog

Sun Feb 22 13:06:30 GMT 2009

permalink BBS2 for a home NAS, part 2: installation and configuration

As mentioned in part one I was hoping to run OpenSolaris on my new Tranquil PC BBS2 server in order to get ZFS for data storage. This opens up a world with automatic, regular snapshots of my data on a solid operating system.

For this server, I chose to use OpenSolaris 2008.11 (known as Indiana) as I might also use it occassionally for a desktop (locally or remotely) in the future.

Initially, I thought I'd try and boot the system from the network as the unit doesn't have a CD/DVD drive. This started off with the automated installer project following this set of instructions from the docs. The first impressions were great, with a simple installadm command to set up the server with DHCP, TFTP and Apache HTTP for serving files.

Unfortunately, it needs working multicast on the network, which isn't something I have functioning here at the moment (plus I was using a VM for the OpenSolaris AI server). I struggled with it for a bit and discovered that there's no support for unicast DNS yet.

At this point, I decided to use a USB stick install as the system appeared to boot from a test DSL USB stick I had lying around (by default, the system seems to boot first to USB, then HDD, then PXE/network). Once I'd gone to buy a 1GB USB stick (the minimum I believe), I used Clay's instructions on an OS 2008.11 VirtualBox VM with the USB stick passed through to the VM. The usbgen and usbcopy utilities from SUNWdistro-const were quick and easy and used the original ISO to write onto the USB key.

OpenSolaris was very easy to get installed and running, booting straight into a GUI, as easy as any Linux distro these days. At this point, the four WD 'Green' 1TB drives arrived, giving me the ability to create a data zpool containing all of the disks. With all four disks, the raw storage capacity is 3.62TB (according to zpool list), which I put into a RAID-Z (like RAID-5) configuration, yielding a usable total of 2.32TB (according to zfs list).

In the last entry, Matt asked whether using the fitted PCI SATA RAID controller (a Silicon Image SIL3124) was a good idea or not. The main issue is with how the RAID ports and disks are configured and secondly, whether the hardware RAID offers the features you need. When you order, there are two options for the layout of disks:

  • Option 3+1: two disks on the motherboard, three disks on the RAID card, eSATA port on the RAID card
  • Option 4+0: one disk on the motherboard, four disks on the RAID card
If you intend to pool all five disks together, then this will be a problem and you'll be forced to use software RAID as the hardware RAID card only covers three or four of the disks. Otherwise, it's feasible to put the OS on the first hard drive and then use the hardware RAID across the remaining three or four disks.

With the power of software RAID nowadays, there's little advantage to be had in using the hardware RAID card (as it's a simple card, with no write-through cache AFAIK) and if anything, you may be limited by not having the data integrity provided by newer generation filesystems such as ZFS (and perhaps btrfs when it arrives).

One occasional problem that I've been experiencing with the BBS2 and its onboard GigE ethernet card (the Realtek RTL8102E) has been prolonged network dropouts. At first, I had problems with my router (some Linksys WGR614) allocating the same IP to the server and another PC. OpenSolaris dropped the rge0 straight into the DUPLICATE state (see ifconfig -a) and it disappeared from the network. However, since I've had a couple of complete dropouts, with the interface simply stopping, no clues in ifconfig, no responses to ARP requests for its IP address and no change when the interface is replumbed.

Jon (who recommended the BBS2) mentioned that the ethernet has problems sometimes with auto-negotiation and forcing it up to 100/full on his network ironed out problems. Unfortunately, this isn't possible with GigE and so I'll continue to troubleshoot this with the switch diagnostics if it happens again.

Update (23/02/09): the network dropouts are continuing, mostly it seems when transferring a lot over data over the interface (e.g. when extracting a large archive onto it). There are no hints on the server that anything's wrong, but it's unable to ping out or reply to pings. No packets are seen through a mirrored switch port.

Update (02/03/09): I've written more about the problem here.

Other related posts:

Archives


Comments for this entry are now closed.