Will LimeTech builds MD-1510/LL and/or MD-1500/LL support 4TB drives?

[hawihoney]

I own two original LimeTech machines: The current MD-1510/LL and the older MD-1500/LL. Both machines are running happily since years with 15 drives each on unRAID 4.7.

 

I'm just wondering if the hardware of these machines, or at least the newer machine, will support 4TB drives with the new unRAID 5.0.

 

I asked LimeTech via Mail some weeks ago but didn*'t receive an answer.

 

Regards and thanks

Harald

 

[dgaschk]

It should but parity checks will take a very long time.

[hawihoney]

Thanks a lot.

 

You know these machines? The older machine is from 2008-01-30 and the newer one from 2008-12-12.

 

If you need some details I would be happy to issue required statements on these machines.

 

Thanks

Harald

 

[limetech]

I'm just wondering if the hardware of these machines, or at least the newer machine, will support 4TB drives with the new unRAID 5.0.

Yes, these servers should support drives larger then 2TB using latest unRaid OS 5.0 release.

[hawihoney]

Thanks for your answer.

 

I thought I would need to change those SATA controllers or install new firmware.

 

Anyway, good news.

 

Regards

Harald

 

[grandan]

I have Tom-built MD-1500/LL-3 from February, 2008 that uses p5b-vm-do mb.  I have expanded memory to 4GB and upgraded processor to E6700 but otherwise hardware is as purchased including Promise PCI SATA cards.  I recently upgraded the hard drives by replacing 11 old 750 GB drives with several 3TB drives and kept two 1TB and one 2TB drives.  It now completes 3TB parity check in appx. 10.5 hours using current 5RC11.  (First TB of parity check averages 45.5 MB/s...oldest drives on PCI cards; second TB of parity check averages 96.3 MB/s; third TB of parity check averages 123.5 MB/s...newest drives on mb ports.  So, overall average of about 79 MB/s.) I am sure that speed will decrease as I add more drives and test the bandwidth of the cards and mb channels.  When I had a 2T parity drive and all the old drives, it took about 30 hours to complete a 2TB parity check so it seems that the quality of the drives has tremendous impact on parity checks, much more than CPU and memory.

[hawihoney]

Thanks for your info. My first machine is identical to your machine. This one is unmodified here.

 

BTW, I don't care about parity-check times. I usually build my machines with all drives at once. My last parity-check was 750 days ago...

 

[Automatic]

BTW, I don't care about parity-check times. I usually build my machines with all drives at once. My last parity-check was 750 days ago...

 

I don't think you quite understand the point of a parity check, it's to verify that the parity is still in sync with the data drives & any of the drives aren't 'slightly' being corrupted.

[JonathanM]

Thanks for your info. My first machine is identical to your machine. This one is unmodified here.

 

BTW, I don't care about parity-check times. I usually build my machines with all drives at once. My last parity-check was 750 days ago...

How do you monitor the health of your drives? If a machine can't successfully complete a parity check, it can't rebuild a failed drive. Unraid is great in that it allows drives to spin down and sleep if they aren't used, which saves electricity. However... If you never test the seldom used drives to make sure they haven't failed, you are risking multiple drive failure without you ever knowing, until the worst possible time when a drive you do use all the time fails, and a seldom used drive is called into continuous action for the duration of the failure and rebuild.

[hawihoney]

I don't think you quite understand the point of a parity check

 

Seems so.

 

What's the difference between unRAID and nearly 10 NAS systems I did own in the last 8 years? They didn't offer a parity-check at all.

 

I do not understand why a piece of hardware might loose a bit.

 

Call me stupid but I never did a parity-check in my life (excpet the forced onces).

 

Regards

Harald

 

[mrow]

I don't think you quite understand the point of a parity check

 

Seems so.

 

What's the difference between unRAID and nearly 10 NAS systems I did own in the last 8 years? They didn't offer a parity-check at all.

 

I do not understand why a piece of hardware might loose a bit.

 

Call me stupid but I never did a parity-check in my life (excpet the forced onces).

 

Regards

Harald

 

 

In those systems, like RAID 5, the all disks are always spun up and parity is spead across all the disks so if there is a parity error it is known right away. In system like unraid where there is a single parity disk and a disk in the array may go months or years never spinning up if the data on them isn't accessed, how can you know your parity calculation is still correct? That is why parity checks are important. There are plugins and unmenu packages that can schedule a parity check on a regular basis for you. I check my parity once per month.

[jbartlett]

To further expand on it:

 

You have 15 drives, likely 14 data and 1 parity. Sometimes, drives start to go bad and sectors become unreadable or totally fail. In this event, the parity drive is used to emulate the failed drive so all your data is still available - and when you replace the failed drive, the parity drive is used to recreate the data from the failed drive onto the new drive.

 

To ensure the data on the parity drive is still valid, you want to occasionally perform a parity check. If the parity is out-of-sync with one or more data drives, bad or incorrect data could be restored onto a replaced drive.

 

Checking the parity is also a quick way to see if all the drives are still functioning as desired across their platters.

[dgaschk]

To further expand on it:

 

You have 15 drives, likely 14 data and 1 parity. Sometimes, drives start to go bad and sectors become unreadable or totally fail. In this event, the parity drive is used to emulate the failed drive so all your data is still available - and when you replace the failed drive, the parity drive is used to recreate the data from the failed drive onto the new drive.

 

To ensure the data on the parity drive is still valid, you want to occasionally perform a parity check. If the parity is out-of-sync with one or more data drives, bad or incorrect data could be restored onto a replaced drive.

 

Checking the parity is also a quick way to see if all the drives are still functioning as desired across their platters.

 

This is not completely accurate. The parity drive and all of the remaining drives are used to emulate the failed drive. If any remaining drive has an unreadable sector then the rebuild of the failed may not succeed. This is why periodic parity checks are essential. A successful parity check indicates that all drives are readable and that parity protection is working.

[boof]

Worth pointing out that any half decent striped raid solution (raid5,6,zfs,linux software raid etc etc) usually allows a background 'scrubbing' of the array to check for problems. This is pretty much the same thing that an unraid parity check is doing.

 

So even with a traditional raid array you should very much be doing 'something' to periodically check the integrity of the array. It isn't something unique to unraid.

[garycase]

"... BTW, I don't care about parity-check times. I usually build my machines with all drives at once. My last parity-check was 750 days ago... "  ==>  Hopefully the above discussion will encourage you to run a parity check on your array !!    You don't necessarily need to do it monthly;  but at least once/quarter is a good idea.    The most frequent cause of parity errors in an UnRAID machine is a power failure, or a Linux "glitch" that results in uncommitted parity writes to the parity drive.    For that reason, UnRAID always assumes that a parity check error is due to a bad bit on the parity drive, and simply corrects it there.

 

The longitudinal parity allows any drive's data to be reconstructed by simply reading every other drive and computing what the bits need to be on the "missing" drive -- but this only works for ONE failed drive ... so be sure you replace any failed drive very quickly and let the new drive rebuild.

 

You can demonstrate UnRAID's reconstruction capability very easily.  Say you have a bunch of movies on Disk 4.    You can REMOVE disk 4 from the system, boot to UnRAID, and still do a directory of Disk 4;  stream movies from it;  etc.  ... and it will work fine.    The data transfer rate will be slower -- but plenty fast for streaming.    You'll also notice that ALL of the drives are spun up while you're doing this; whereas only Disk 4 would be spun up in normal operation.