Poojan's Tech Blog

In a prior incarnation of my “RAID” system, I was using 1 partition on one drive plus 4 partitions on another drive to set up a RAID-Z2 system.

My thinking was that splitting up by partition at least protects me against sector failure (if not whole drive failure). The 4 partitions were 250 GB each on a 1TB Hitachi/SimpleTech drive.

I should’ve anticipated it, but don’t you know, the 1 TB drive failed–after about 1 week. So, my data would’ve been lost. (Except I kept a copy on another computer; I’m not crazy.)

I knew I’d need at least 3 hard drives to prevent this from happening again. So, I sent the Hitachi drive for warranty and ordered a Fantom 1 TB hard drive. (BTW: I really like the Fantom; it looks slick, is constructed well, and runs rather cool.)

In the meantime, I spotted a 500 GB Fantom for a good price (not too enthused about the mail-in-rebates, though), so I got that as well. Once I had the two Fantoms in hand, I could set up a RAIDZ (2 data + 1 parity) configuration with what I already had: a 250 GB Cavalry hard drive (from before), a 500 GB Fantom, and a 1 TB Fantom. Setting it up this way meant that I’d only be making use of 750 GB of space (out of the 1.75 TB that all the drives have together). 250 GB of that 750 is used for parity, so I really only get 500GB of usable space. Such is the price for reliability.

A couple days ago, the replacement 1 TB Hitachi arrived. So, I decided to take out the 250 GB hard drive and replace that slice with the 1 TB Hitachi. I did a:
sudo zpool offline tank da1s1
I then powered down and unplugged the 250GB Cavalry drive. Seeing as how FreeBSD can be quite flaky in disk numbering, I made sure to keep track of which USB port it was plugged into.

Incidently, I had a Kill-A-Watt on the whole setup. Before unplugging the Cavalry, the Kill-A-Watt estimated $36.33 per year and 33 Watts usage. After unplugging, it said 22 Watts usage. Wow! That explains why the Cavalry runs burning hot to the touch (makes a good foot warmer in winter).

After plugging in the Hitachi drive (I inadvertently powered down the machine in the process), I did the following to re-silver:
sudo zpool replace tank da1s1 da1s1

Right now, it’s sitting at the following:

errors: No known data errors


Pretty slick! I’ll now have 1 TB of storage (out of the 2.5 TB total hard drive space).

I know it seems crazy, but I think I’ll continue to keep the slices incongruent. For example, when I need more space, I’ll replace the 500 GB drive with a 2 TB drive. I’ll immediately have 2 TB available (out of a total of 4 TB hard drive space, 3 TB are being used). One of the mistakes I made presently is that I have two drives of the same size. So, at some point, I’m going to replace one of them but not get any additional space from it. More likely, 2 TB of space will suffice for many years to come.

By the way, the Kill-A-Watt now shows 30 Watts usage. Of course, that’s while the drives are active (re-silvering). Hopefully, they’ll lower their power when the re-silvering is finished.

Be the first to like.

Like

Unlike

So, as it turns out, ZFS relies on the FreeBSD slice names to determine what goes where. This can be a problem, since the slice drive names can move around–if, for example, you switch what USB ports your drives plug into. Which is what I just did.
I have no idea what ordering they were before, but I figured out how to find out what they are now. I did a:

dmesg | egrep “da.:”

Which resulted in:

Be the first to like.

Like

Unlike

I expose an ssh server to the internet. This allows me to sync up git or hg repositories under a secure connection (without requiring SSL)–but more importantly, keeping the data stored in those repositories under my control.
Since I’m fairly paranoid about security, I chose a random port number (my router routes the random public port to the usual internal port: 22). In addition, I disable password login, which means that I can only log-in using an ssh key. More importantly, other people can’t login using passwords–which means that there’s not possibility of a dictionary (nor simple brute-force) attack.
Here’s the sshd_config file for FreeBSD that does this:

# $OpenBSD: sshd_config,v 1.74 2006/07/19 13:07:10 dtucker Exp $
# $FreeBSD: src/crypto/openssh/sshd_config,v 1.42.2.4 2006/11/11 00:51:28 des Exp $

# Example of overriding settings on a per-user basis
#Match User anoncvs
# X11Forwarding no
# AllowTcpForwarding no
# ForceCommand cvs server

I’ve disabled all authentication types (including PAM)–at least the ones that aren’t disabled by default. Since public key authentication is on by default, I don’t have to change it.

You’ll notice that I’ve disabled tunneling (to disable people from penetrating past the FreeBSD machine into my home network) and chosen not to enable X forwarding (no need for it in this case).

Be the first to like.

Like

Unlike