So I have basically decided to join the cult

 

I'm 'migrating' from a windows home server that blew the backplane with 8 drives total.

I have a new case, new power, older usb, older MB. At this moment in time it is running the demo 3 drive version.

 

As I am budget limited, I can't purchase the key and a new MB at the same time. So between upgrading the MB and getting the registration key which should be done first? My new MB will have 3/4tb capability and as many sata ports as I can find on the affordable shelves at MicroCenter.

 

I already plan on starting migrating the data and disks to the current 3 drive system (which has 3 small drives) and moving the 1.5 and 2tb from the dead system into the demo system.

 

Good idea? Bad Idea?

 

 

 

That's essentially where I came from as I joined the unRAID brigade, but I moved the drives out of my primary WinXP desktop box before it failed (thankfully!).

 

I got the Pro key and went with existing hardware. I'm still running the old MoBo with old CPU (Athlon 2500+, single core!), but have 11TB shoehorned onto it. I've reached the limits of this hardware (only 2 SATA ports on the MoBo), and am now looking at an upgrade for that.

One of the beauties of unRAID is it does not care much about hardware.

 

Since my initial install about 3.5 years ago, I have replace the motherboard and several internal parts without issue. All piece-meal. No ties-ins to hardware ID's.

 

You can safely buy your license in knowledge that you may upgrade at your own pace, and in your own time.

 

Welcome to unRAID!

 

bkasten

 

I have replaced all of my hardware except some of the drives since I first built my system over 2 years ago. No problems.

Lots of performance testing has been done on unRAID, but its scattered all over the forums.

What you'll find is that nearly all setups are most constrained by the speed of the parity drive as data is written, and not by your MB. The parity drive must read the other disks, the CPU calculate a check sum and then write that value to the parity drive. This constrains throughput to about 30 Meg no matter how fast your processors, LAN, CPU, etc.

 

 

Like the others say, in your situation, I'd go for the pro-key first, and upgrade your server hardware as you encounter constraints.  The order of upgrades I found was:

1. key for unRAID

2. a 3TB parity drive (that seems to be the most cost effective drive size at the moment) Note that your existing MB must be capable of handling drives larger than 2.2TB...unRAID itself is fine, but some drive controllers and MB BIOS are not. Also, your parity drive needs to be as big as, or bigger than, any individual data drive...so plan ahead.  Once the parity is the right size, then start adding in your other drives as data drives, with an occasional new 3TB drive.

3. a cache drive (even a small one) can dramatically increase your data transfer rates.  You may already have one that you can reuse.  Just watch the total power requirements and be sure your power supply is adequate.

4. memory for unRAID...there's not as much discussion about this, but 4Gig seems to be the sweet spot. unRAID will work with less (with a minimum of 2(?)), but if you start adding plugins, media server software, etc., you'll want the memory. If you're existing MB and planned new motherboard don't use the same memory chips, save your money for the new MB.

5. a SATA controller add-in card when you need more than 4 SATA drives. There's lots of discussion about these, and some brands don't work well--check the forums before spending your green. I found that FOUR seems to be the cost effective number of SATA controllers on inexpensive motherboards. Six ports can be found, but are generally more expensive.

6. Finally, the motherboard and new CPU chip.  If you're going to have a lot of add-ins, you may want a faster CPU...if you're just serving up data files, you don't need much CPU power. I run PLEX for serving movies...I normally do all transcoding on my Mac before moving the media to unRAID for storage...If I stream the media to my tablet, PLEX does some work to convert the format...still, the CPU is rarely over 10% load. (an Intel i5) I could have easily saved money and used a much lower power CPU. [Again, the real constraint is in writing to the hard drives and the need to recalculate parity] Reading data is blazing quick and constrained by the speed of the network, and the rotational speed of the data drives.

7. Through all of this, watch out for power requirements...if you were running 8 drives before, you're probably okay, but you don't say how your old server 'blew the power supply'

 

 

...and we're not a 'cult'..."Here! Have some more Kool-Aid!" 

Thanks all for the quick responses.

 

My MB is an old dell, so I am Ivory Certain (99.44%) certain that it can't deal with 3/4tb. I'll deal with that once I have the system fully populated.

 

FreeMan: Thankfully it was a WHS system, which means all data is available through a dock.  It behaved similar to unraid, but lord gates' people decided to drop it.

 

DalwWilliams: Thanks for the warning. I have a 4port sata card, I'll double check it against the list before I install into the system.

 

The old system had a mixture of 1.5 and 2tb drives and I'll migrate the 2s first, then start upgrading to 3/4. Extra drives can fit in an external 4 bay esata/usb case I have that I can drop on my desktop system.

Lots of performance testing has been done on unRAID, but its scattered all over the forums.

What you'll find is that nearly all setups are most constrained by the speed of the parity drive as data is written, and not by your MB. The parity drive must read the other disks, the CPU calculate a check sum and then write that value to the parity drive. This constrains throughput to about 30 Meg no matter how fast your processors, LAN, CPU, etc.

This is incorrect.

 

The parity disk does not READ any other disks, ever.  On an initial parity calculation the CPU reads all the data disks and writes to the parity disk.  The entire process cannot go any faster than the SLOWEST disk in your array.  It does not matter how fast the parity disk is (unless it is the slowest disk in the array)

 

On subsequent "writes" to the array, both the data disk being written AND the parity disk must FIRST be read, then parity is calculated based on their current contents, and the new data being written.  Then BOTH disks platters  must rotate a full revolution before they can write their same respective sectors on the disks.    the MAX speed possible when writing depends on the SLOWEST ROTATIONAL SPEED disk involved.    If you have a 7200 RPM parity disk and a 4800 RPM data disk, the slower rotational speed of the data disk will limit how fast writes occur.

 

The only times a faster parity disk will help is if all the disks are that SAME faster speed, OR when multiple data disks are being written to simultaneously.  When that occurs the parity drive will be read and written to twice as often than each of the two data drives.  At 7200 RPM, it will better be able to keep up, but only if the data disks are both slower than 7200 RPM.  If both data disks simultaneously being written  are 7200 RPM, then the parity disk will be the bottleneck.

 

The 30MB/s rate when writing to the array is limited by how fast the disks can rotate between reading and subsequently writing any given single sector.

 

There is an exception to this in the most recent 5.0.4 release.  There is a tunable that can change how unRAID writes to disks.  It comes at a cost in that ALL disks must be spinning and on any write ALL data disks are read, and the parity calculated and then written to the parity disk.  That is more like a standard raid4 operation.  If that mode is enabled ALL disks will ALWAYS be spinning when writing to the array and power consumption and disk noise will be higher.  (Some users will not care that operating cost and noise are higher... To them, write speed is more important.  for other who write movie data infrequently compared to playing movies, the lower noise and cost of power used is more important and the default unRAID read/write mode is preferred)

 

This optional "write" mode will allow writing as fast as the PCI bus (and disks) permit.  Many will get 80-90 MB/s.  Again, write speed is limited by the SLOWEST data transfer rate disk, so it does not matter if the parity drive is faster or not.

 

Joe L. 

 

Lots of performance testing has been done on unRAID, but its scattered all over the forums.

What you'll find is that nearly all setups are most constrained by the speed of the parity drive as data is written, and not by your MB. The parity drive must read the other disks, the CPU calculate a check sum and then write that value to the parity drive. This constrains throughput to about 30 Meg no matter how fast your processors, LAN, CPU, etc.

This is incorrect.

 

The parity disk does not READ any other disks, ever.  On an initial parity calculation the CPU reads all the data disks and writes to the parity disk.  The entire process cannot go any faster than the SLOWEST disk in your array.  It does not matter how fast the parity disk is (unless it is the slowest disk in the array)

 

...

I stand corrected! That's a much better explanation, Joe L. Thanks for that.