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.
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.