Looking forward to move on to the new Kernel, I am interested to know if there are any of the 6-8 port on-board SATA (I guess they are workstation board like the supermicro X6DHT-Gs; tyan n3400b, etc) known to be supported?

 

Genereally, what is the best performance board +as few as possible  PCI-e card(s) combo currently seen to support the 14 drive configuration?

 

thanks

See my thread over here:

http://lime-technology.com/forum/index.php?topic=571.0

 

Asus P5B-E is looking promising with support for all 8 onboard SATA300 (6 x ICH8R + 2 x JMicron) + Attansic L1 GigE LAN.  This looks to now be up and running as at this morning, with V4.0-beta9 release (resolving earlier unRAID beta7 startup issues experienced by several of us).

 

I am using the 6 x onboard ICH8R SATA300 ports, plus will be adding 2x Promise SATA300TX4 cards, to build a fast 14 x SATA 300 configuration, using a CM Stacker C310 case and Seagate 500GB SATA drives.

I am using the same MB with this case:

 

http://www.newegg.com/Product/Product.aspx?Item=N82E16811112062

 

12 internal HD bays, plus 7 external 5-1/4 bays; a single 5-in-3 mount and a pair of 3-in-2 mounts and I could fit (2+1=3, no carry...) 23 HD in the case, plus one external via the eSATA port on the MB.

 

7 internal SATA ports on the MB, plus 3 PCI slots @ 4 SATA ports per controller yields (3*4=12, +7...) 19 internal SATA ports plus one eSATA. Hm. I'd need a PCI-e SATA card to max out the case. 23 internal and one eSATA - 24 drives. 

 

Hm. Another PCI-e controller, and one of these (http://www.cooldrives.com/intoexes4pop.html) plus a 4 bay external case (http://www.newegg.com/Product/Product.aspx?Item=N82E16817994037) - 28 drives. 

 

14 drives is starting to seem like a low limit... 

14 drives is starting to seem like a low limit...   

 

Has Tom mentioned why there is a 14 drive limit? Or, why he came up with 14?

 

14 is an odd number in the PC world.  With the config I mentioned above, the 2 x JMicron onboard SATA ports remain unused.  Also, if you use the well regarded CM Stacker case with 4 of the standard CM 4-in-3 modules, the case nicely holds 16 drives.

 

16 is a nice power of 2, so why does the unRAID software limit to 14 instead of 16 drives?

 

This probably belongs in the suggestions forum, but wouldn't it be great if a future version allowed:

 

- Perhaps up to 32 drives.

 

- An option for a 2nd parity drive for large array's, such that any 2 drive simultaneous failure could be recovered (like RAID6).

 

Given unRAID's energy efficient ability to spin-down all drives, and only spin-up the drive fith the files being accessed, this power efficiency should make it viable to have much larger drive arrays.

 

14 drives is starting to seem like a low limit... 

 

Has Tom mentioned why there is a 14 drive limit? Or, why he came up with 14?

 

14 is an odd number in the PC world.  With the config I mentioned above, the 2 x JMicron onboard SATA ports remain unused.  Also, if you use the well regarded CM Stacker case with 4 of the standard CM 4-in-3 modules, the case nicely holds 16 drives.

 

16 is a nice power of 2, so why does the unRAID software limit to 14 instead of 16 drives?

 

This probably belongs in the suggestions forum, but wouldn't it be great if a future version allowed:

 

- Perhaps up to 32 drives.

 

- An option for a 2nd parity drive for large array's, such that any 2 drive simultaneous failure could be recovered (like RAID6).

 

Given unRAID's energy efficient ability to spin-down all drives, and only spin-up the drive fith the files being accessed, this power efficiency should make it viable to have much larger drive arrays.

 

 

Since I have brainstormed a way to up my above 28 drive config to 32 drives (23 internal and 9 eSATA), I'd be all for that.

The number of drives in an array does not matter too much when all the disks are working properly in an unRaid system.  It does matter when rebuilding parity or reconstructing the contents of a failed drive on the fly.

 

To reconstruct the contents of a failed drive ALL the other drives must have the same block read and then the results all combined with the parity drive to reconstruct the failed data.    So, on a 14 drive array, 13 read requests, one to each of the working drive must occur. (in addition to writing a block to the drive being rebuilt)

 

When Tom originally tested using IDE drives and PATA controllers he ran into a PCI buss bottleneck when he went over 12 drives.  That is the reason for the original 12 drive limit.  With SATA support, he felt he could up that to 14 and still have reasonable performance.

 

You could theoretically calculate parity on 10,000 drives, but to reconstruct a failed drive, or to calculate parity would take 10,000 read commands, one to each disk.  Performance would drop to nearly nothing on the single PCI buss.

 

The limit on drives in an array is a tradeoff on performance.  Most RAID arrays limit you to 10 or less since most must read ALL the drives ALL the time for any file.  (Unraid has an advantage here)

 

Joe L.

Ah. That makes a *lot* of sense. (Need to go edit another post I just made...)

 

So, for the kind of megabuild I'm envisioning (although I plan to use the external drives for backup to disk, so I'd be looking at 23+/- drives in the case for data and parity), maybe two or three separate arrays would be wise...

Yes, thanks Joe.  That explanation actually does make complete sense.  I'm assuming from this that the time taken to rebuild a failed disk is therefore relative to the number of drives in the array.  ie. A 10 drive array takes longer to rebuild a failed disk, than a 2 drive array (although it would not be a linear relationship as multiple drive reads presumably happen in parallel, but ultimately limited by the bus bandwidth as you mentioned etc.).

 

Also, a larger array of drives (more than 12 or 14) is probably actually unnecessary given the inherent expandability of unRAID.

 

ie. For most peoples requirements, if we build up to a 6TB array now (with 500GB drives), by the time we actually need more space we will probably just be swapping out our "tiny old 500GB drives" for the latest cost effective 2TB of 4TB SATA drives.  Then, by the time we need even more space, we will likely be building a completely new media server from scratch, to replace the slow old obsolete SATA interfaces in our old aging servers.

 

 

Yes, thanks Joe.  That explanation actually does make complete sense.  I'm assuming from this that the time taken to rebuild a failed disk is therefore relative to the number of drives in the array.  ie. A 10 drive array takes longer to rebuild a failed disk, than a 2 drive array (although it would not be a linear relationship as multiple drive reads presumably happen in parallel, but ultimately limited by the bus bandwidth as you mentioned etc.).

Correct.

Also, a larger array of drives (more than 12 or 14) is probably actually unnecessary given the inherent expandability of unRAID.

 

ie. For most peoples requirements, if we build up to a 6TB array now (with 500GB drives), by the time we actually need more space we will probably just be swapping out our "tiny old 500GB drives" for the latest cost effective 2TB of 4TB SATA drives.  Then, by the time we need even more space, we will likely be building a completely new media server from scratch, to replace the slow old obsolete SATA interfaces in our old aging servers.

My unRaid server is around 18 months old.  It is entirely PATA.  At the time a 500Gig drive was the biggest available.  I started with 2 of them.  (one was the parity drive) 

 

I'm now up to 8 drives total and 4 empty slots in my stacker case.  I've currently got about 2500GB of data storage.  As you said, once it is filled, the 1000Gig drives will be affordable. I'll probably eventually fill the server, but it takes a lot of DVDs to fill 13,000 Gig.

In fact, over 2100 DVDs if they average 6Gig each, and many are between 4 and 5Gig so I'm, guessing it will hold  over 2500 DVDs if I just keep the main movie.  That's about 5 times the size of my DVD collection...  Might take me a while to find I even get to where I fill the array.