If you’re in the market for an understated, quiet case that performs well and leaves plenty of room for expansion the Fractal Design Define series is quite likely to be on your list of cases to investigate. The latest revision of the case is R4, which draws upon user feedback on the R3 and features a host of minor changes. So how does it fare?
With the release of the Fractal Design Define R4 we have been asked a few times about whether Corsair’s self-contained liquid cooling system will fit in the front. Placement here has a few advantages over placing it in the top of the chassis; noise is reduced, for a start, and if you use the top as an intake you lose the inbuild dust filters. You could use the H100 in an exhaust configuration in the top position but temperatures will not be as good as you will be drawing in warm air from inside the chassis to cool the CPU rather than the cooler, outside air.
That leaves the front as an ideal position from the perspective of noise and cooling; the Define R3 did not allow this placement without drilling out the front drive bays. Since the R4 allows you to remove the front drive trays without permanently modifying the chassis, how does the H100 fare in terms of fit?
As it turns out, it fits beautifully:
From the front we can see:
Someone asked how we removed the hard drive bays in the Fractal Design R4 builds we’re doing at the moment, so we wrote up a quick post for those who are wondering. If you want to install a radiator to the front of the R4 or are simply using a handful of SSDs and have no need for the 3.5″ drive bays you may wish to remove them; unlike the R3, where they’re riveted in place, the R4 features entirely removable drive bays.
Now we have a front chassis that’s empty – until you install a radiator, that is… here’s a view of the newfound free space:
Here is a comparison of the Define R3 and R4, side by side – the R4 is the larger, black case and the R3 is in white.
When the front panels are lined up like so…
The rears meet like so:
Same length! As for the width:
As you can see the R4 is substantially wider – it also replaces the grille and twin rubber grommets for water cooling with a vertical PCI expansion slot, which is arguably more useful. The rear exhaust fan mounting has gone from a 120mm-mount to a 140mm mount – 120mm fans can also fit, mind. The front intake and top intake/exhaust fan mounting points are also 140mm-compatible now as well on the R4 (again, 120mm still fits).
As you can see the R4 is slightly higher, too.
More comparisons to come as well as a full write-up of the R4 🙂
Sometimes you may wish to expand a two-way mirror to a three-way mirror, or to make a basic single drive vdev into a mirror – to do this we use the zpool attach command. Simpy run:
# zpool attach [poolname] [original drive to be mirrored] [new drive]
An example:
# zpool attach seleucus /dev/sdj /dev/sdm
…where the pool is named seleucus, the drive that’s already present in the pool is /dev/sdj and the new drive that’s being added is /dev/sdm. You can add the force switch like so:
# zpool attach -f seleucus /dev/sdj /dev/sdm
to force ZFS to add a device it thinks is in use; this won’t always work depending on the reason why the drive is showing up as being in use.
Please note that you cannot expand a raidz, raidz1, raidz2 etc. vdev with this command – it only works for basic vdevs or mirrors. The above drive syntax is for Ubuntu; for Solaris or OpenIndiana the drive designations look like c1t0d0 instead, so the command might look like:
# zpool attach seleucus c1t1d0 c1t2d0
…instead.
This is a handy command if you want a three-way mirror but don’t have all three drives to start with – you can get the ball rolling with a 2-way mirror and add the third drive down the track. Remember that ZFS performs reads in a mirror in round-robin fashion, so that while you get a single drive’s performance for writes you will get approximately the sum of all of the drives in terms of read performance – it’s not hard for a 3-way 6gb/s SSD mirror to crack 1,500MB/s in sequential reads. It’s a fantastic way to get extreme performance for a large number of small VMs.
One of the most significant features of the ZFS filesystem is scrubbing. This is where the filesystem checks itself for errors and attempts to heal any errors that it finds. It’s generally a good idea to scrub consumer-grade drives once a week, and enterprise-grade drives once a month.
How long the scrub takes depends on how much data is in your pool; ZFS only scrubs sectors where data is present so if your pool is mostly empty it will be finished fairly quickly. Time taken is also dependent on drive and pool performance; an SSD pool will scrub much more quickly than a spinning disk pool!
To scrub, run the following command:
# zpool scrub [poolname]
Replace [poolname] with the name of your pool. You can check the status of your scrub via:
# zpool status
The output will look something like this:
pool: seleucus
state: ONLINE
scan: scrub in progress since Tue Sep 18 21:14:37 2012
1.18G scanned out of 67.4G at 403M/s, 0h2m to go
0 repaired, 1.75% done
config:NAME STATE READ WRITE CKSUM
seleucus ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
sdh ONLINE 0 0 0
sdk ONLINE 0 0 0errors: No known data errors
Scrubbing has a low priority so if the drives are being accessed while the scrub is happening there should be less impact on performance. It’s a good idea to automate the scrubbing process in case you forget – we will do a later post on just how to do that!
We got some new gear in-house – while a full review is coming, here’s a teaser photo…
After upgrading to 12.04 people seem to be finding that their ZFS shares aren’t mounting on boot; this has an easy fix, fortunately – edit your /etc/rc.local file and add:
stop smbd
stop nmbd
zfs mount -a
start smbd
start nmbd
Save and reboot and your shares should be intact. This has worked on all of the systems we’ve tested it on so far.
We had some requests for a 1U sensor that did more than just read the temperature in one spot in the chassis and after looking at what was available we decided to make our own.
Featuring two temperature sensors with 1M probes and an ambient temperature+humidity sensor, it’s a great way of measuring intake/exhaust temperatures as well as the internal rack temperature with the added bonus of humidity. At 1U it takes up a minimal amount of rack space and the probes are quite thin, making it practical to route them around your rack.
Let us know if you want one included with your next server build!
Note: This also works in other versions of Ubuntu, such as 11.10, 11.04, 10.10, 10.04 and earlier.
Sometimes you may wish to find out which kernel you’re currently running; fortunately, this is quite easy to do with the uname command. If you’re running Ubuntu Desktop, open up a Terminal; if you’re using Ubuntu Server log in as per usual and then run:
uname -v
…for the kernel version, or:
uname -r
for the kernel release. You can combine the two and use:
uname -rv
to see both of those with the one command.