unRAID Media Server Online: Part 2.

By | March 7, 2008

I’m going to have to backtrack a few days now that the server has been up-and-running since Wednesday. I had planned a very thorough setup, but I’m not going to go through with that anymore. The Project Gallery entry gives enough background so that I don’t have to do that. Plus, I followed the unRAID installation instructions to the letter, so I don’t see any point in repeating them. I will, however, explain a few of the “gotchas” I encountered on the way.

The first problem I encountered happened to be with only one of three drives being detected within the BIOS. I knew the enclosure was not the issue as the populated bays were all orange when powering it on for the first time. That left the connection from the rear of the enclosure to the SATA ports on the motherboard. After closer inspection, I found the culprit. The eSATA cables I bought were not capable of being plugged all the way into the ports on the back of the external enclosure. As you can see, the ports are located very closely to the edge of the cutout in the back of the enclosure.

The eSATA cables were not really at fault since they’re all pretty much made the same way. The molded shroud was hitting the back of the case and not allowing it to be inserted all the way. The two top ports were fine, but it was the two bottom ones that I was having difficulty with. Therefore, only SATA01 showed up. I used a utility knife to cut back about 1/10″ off of the offending part of the shroud. After plugging it back in and entering the BIOS, it was a success. I then continued on to configure the remaining pages of the BIOS, which is where I encountered my second, and more frustrating, issue.

After setting the BIOS according to the recommended settings by the unRAID installation manual (as well as using some technical common sense), I was ready to save and exit. This is where I would begin the immediate reboot and loading of the unRAID OS…except all I received was “BOOT ERROR”. I knew that I had prepared the flash drive correctly. In fact, I initially used the same flash install that was working at work with my VMWare setup. I took the flash back upstairs to my office, reformatted it, used syslinux to set the boot record, and copied the unRAID OS to it once more anyway…just to cover the bases. It was futile. I received three different types of error messages – all indicating no boot device or invalid boot ID. I must have changed settings in the BIOS 30-40 times over the next couple of hours with no love. Even though I was sure that I had set it once before (I don’t know how it would be possible for me to miss after all the combinations of settings made), I enabled a setting that forced all removable devices to appear as fixed disks. I saved and exited and was finally met with the unRAID OS/MEMTEST x86 screen! Success!

After finally making it to the login prompt and connecting to the web administration for the first time, I continued to set up my new unRAID server. I assigned two drives to the data slots, then mounted and formatted them. I did not initally setup theparity drive though. After weeks of reading in the unRAID forum, I came across a tip that saved me several hours of data transfer time. By not enabling the parity drive prior to data migration, transfer rates can be at a maximum since the parity calculation is not taking place concurrently. Since there is the original storage target, there is no need to have the redundancy feature enabled on the unRAID server yet. This definitely helped as I found a transfer with the parity enabled only went about 100Mbps (it would hit 400Mbps+, but fluctuate to nearly a halt while the parity was being computed), whereas without it I average nearly 400MBps over 1TB of data.

After several hours of transferring the data to the drives, it was complete and I could enable the parity. That took about another 5 hours (I’m not real sure as I just let it run, but unRAID estimated 5 hours).

At the moment, I have not assigned my HTPCs to use the unRAID server. I’m just letting it run through a “break-in” period. I’ll probably switch a single system to it first just to see how it’s going to handle the disk spin-down feature. I’m curious as to how long the delay will be for that. I really love the idea since this is an “always on” system and the disks can spin down overnight, when not in use. I have it set to a 2 hour period of inactivity now, but that will be moved up to 1 hour if the delay does not cause issues.

Well, that’s it for my unRAID server build. Please feel free to leave comments, questions, or words of advice.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.