Building the array
A word of warning to the wise here, and one I pass on from bitter experience: if you’re planning on running an unRAID system on one of VIA’s EPIA motherboards in the hope of having a low-power RAID server, you’re best going back to the drawing board. The Linux kernel that unRAID uses, which is based on Slackware, hasn't been compiled with the option of using VIA's C7 CPUs – you’re stuck with AMD or Intel processors.
There are ways of compiling unRAID's kernel to work with non-AMD or Intel motherboards, but that kind of defeats the whole point of using precompiled binaries in the first place. If I wanted to mess around with compiling kernels, I'd install
Gentoo. Another gotcha is that the system has to be able to boot from a USB drive as well, so any ideas of using a motherboard any older than a couple of years also gets chucked out of the window as well.
That said, there are plenty of low-power systems out there that are perfectly capable of running unRAID since, for the most part, the most strenuous thing the system has to do is calculate or check parity every once in a while. If you’re a little unsure, unRAID has a thriving
forum where you should be able to find out whether or not your motherboard will work with unRAID.
In the end, I let the wallet moths fly free for a bit and forked out for a cheap AMD Athlon X2 motherboard, complete with processor and memory for under £100, and I already had a spare case and PSU to chuck everything inside. Luckily the system was also able to boot from a USB drive, so I could finally get the array setup.
Setting up an array on unRAID is simple. After the hard drives are all connected and the system has booted successfully, everything is managed from a very simple web interface. Assign the largest drive in the system to be the parity drive, assign the remaining disks and go and make a cup of coffee or four while the disks are formatted and the parity data is calculated.
Click to enlarge
Once all that tedious stuff with parity is finished, it's time to sort out the shares. unRAID uses Samba for its shares, but there are a few additional bits to worry about. It is possible to set up user-level security, but since the unRAID server is only going to be accessed by the HTPC and my network sits safely behind a firewall, I decided to forego this step and make all shares available to everyone on the network.
As well as the standard Samba share details such as share name, there are two unRAID-specific settings to take into account:
Allocation Method determines which disk on the server new files will get written to. "Fill up" will fill up each disk in the array before moving onto the next disk; "Most free" will choose whichever disk has the most free space on it; and "High water" will choose the disk which currently has the least free space that is still above a certain minimum. The advantage of using the "high water" method is that most of the time only one drive in the array will be working at any time.
The other main setting to note is the
Split Level option: this determines how much of a directory structure is split between multiple disks. Since we're building this RAID machine to serve up DVD movie files, it's important to get this setting right: we don't want the files of one movie shared over more than one disk. If that were the case, we'd have a pause in the middle of a film as a new disk span up. Not good, especially since that's the kind of thing that gets the wife asking awkward questions, such as whether it would be easier to just play the film from the original DVD.
Click to enlarge
A Split Level value of 0 means that all files for a share would be kept on the same disk where the share was created; a value of 1 would keep files ordered by the first directory level; a value of 2 would keep files ordered by the second directory level; and so on. A value of 999 would allocate files purely according to the Allocation Method setting. Because I store all my movie files in DVD format, I don't want a pause in between separate VOB files which might happen if the DVD title was allowed to be stored on multiple disks, so I use a value of 1 for Split Level.
One final setting to be made – which I didn't discover until using the whole system together for the first time – was to change the default spin down delay to one hour. I found that, without changing this setting, the drives were spinning down as either the unRAID server or the movie player were loading the whole VOB file into memory at once rather than streaming from the disk. This meant that when the next VOB file was ready to be opened, the drives had to spin up before serving the file, leading to a pause every so often throughout the movie.
I wasn’t too happy about leaving the RAID server on 24 hours a day, but there’s a
handy script written by some unRAID forum members that puts the server into S3 sleep mode given a set of circumstances. This can include waiting for all disks to spin down; no network activity within a certain time; specific time conditions; or certain client machines being switched off. I set the server to respond to wake on LAN commands in the BIOS, which means that any client on the network can wake up the unRAID server as and when needed.
Want to comment? Please log in.