A double parity drive would sell me on it. I know people are all hyped about the 3tb HDD support, but in the real world, drives fail. Also the more drives in the array, the more likely of a multi-drive disaster.

This also makes an argument in favor of 3TB drive support, because your quantity of drives is 33% lower for the same capacity as 2TB drives.

 

Well you could say that, but in my personal experience. The early adopters of new hard drives have had many issues with the 1TB drives and larger where they look all fine and dandy and fail.

3TB is a lot of data to loose to me. I recall the seagate and WD forums filled with people bitching about drive deaths with every new drive generation.

 

but i know where your coming from. there are always two sides to the coin. you want to go higher density. as i would also, especially as the price point for a 3TB drive is going down to close to 2tb prices. (It might already be at the point per GB is cheaper with the 3TB drives with sales right now).

 

I want to make sure that I am covered with double parity as we go denser.

 

In the end you have better data protection and more space on your storage server. that is if you get double parity and the 2.2TB barrier broken.

 

today a double failure is only 2 or 4 terabytes lost if you loose 2x1TB or 2x2TB drives. As we go 3TB and 4TB drives. that becomes 6TB or 8TB lost in a double failure. I dont know about you, i rather not loose any data, but that's a big chunk lost.

 

and yes i am aware of unRAID pool vs Hardware raid differences. That's why i am looking into the product.

 

Also, I never put a drive into production without low level formatting it, zeroing it, smart checking, using the correct drive testing software from the manufacture and then filling it up 100% with random data at least once. i have a testing rig that has a tray-less caddy and a bootable thumb drive with all the tools on it to test a drive. I'm a bit of a junky, i tend to buy 1-4 HD's a month. I like to have a few ready to go if i need them.  Im sort of glad unraid forces the zeroing and reading of a drive before use.

 

And yes, i do have a pile of 500MB, 1tb and some 1.5's i have no clue what ill do with. maybe soonish, 2TB drives.... maybe I'll build some 4, 8 or 16 bay servers filled and sell them cheap on bay as porn servers?

 

Anywho, in the end. i have 2 norco 4224's now that i'd love to fill out and make sure i dont loose my data.

thanks for your thoughts.

but Raj is assuming a Reed-Solomon calculation pattern, and there have been discussions over the past year about diagonal parity instead.  Lime-Tech initially indicated an inclination towards Reed-Solomon, but I think the P+Q Project should really just be called "Dual Parity" for the time being.  Raj's comment is very accurate, but it assumes one method for dual parity calculation, and there are in fact several for Lime-Tech to choose from.

 

Sorry to keep the off-topic discussion up, but from what I can see, Raj appears to be talking about diagonal parity.

 

Also, on the topic of Reed-Solomon, one commonly used feature of unraid is to spin down unused drives.  Unlike DP, Reed Solomon requires all drives to be spinning for writes -- so I certainly hope Limetech doesn't choose this approach for DP.  Reed Solomon would also be more demanding than Diagonal Parity -- though even some of the lowest horespower unraid systems in use would likely have no problem dealing with it.

 

Back on topic, it would make sense to increase the maximum number of drives right along with DP.  If the array is to be expandable without needing to recalculate parity for all drive after adding a new drive,  placeholders filling the void between the current number of drives installed and the maximum number of drives possible in the array will need to be used in the calculation of DP.  If unraid later increased the maximum number of drives, and that number exceeded the "placeholder" devices used in DP calculation, DP would need to be recalculated.

 

Im sort of glad unraid forces the zeroing and reading of a drive before use.

 

That actually is not true.  unRAID's default zeroing process just writes to the drives, it does not read from it.  That is why we always recommend running a parity check immediately after adding any new drive, as the parity check will read from the entire drive.  The preclear script does one better - it fully reads the drive, then writes to it, then reads it again.  This gives the drive a chance to run full SMART diagnostics and give you a nice output report.  I personally trust the preclear script just as much as any other drive diagnostic system I've used.

 

Sorry to keep the off-topic discussion up, but from what I can see, Raj appears to be talking about diagonal parity.

 

Correct, that explanation was for diagonal parity.  I believe that Reed Solomon has been discussed and discarded by the unRAID community for just the reason you pointed out - it would require all disks spinning for writes.  Ultimately it is up to LimeTech which dual parity scheme they want to implement, but I find it very hard to believe that they would choose a scheme that negates one of unRAID's most salient power saving features.  It seems to me that diagonal parity is the logical choice at this point, but perhaps there's some other dual parity scheme that I'm not aware of that is even better.

 

My contribution to the fledgling on-topicness of this thread is that I would like to see an array expanded to 23 data drives BEFORE dual parity is implemented.  The Norco 4224 is a very popular case at the moment, and I see no reason why unRAID couldn't be the perfect compliment to it.  I personally trust unRAID enough that I would build a 24 drive server with just a single parity drive if I needed one (which I don't - my 9 drive server is plenty big enough for me).  Of course I do want to see dual parity implemented eventually, but I don't think that 23 drives protected by a single parity drive is much of a risk.  This opinion is based on my own testing and use of unRAID in various environments.  It is one of the most stable bits of software I've seen to date.

 

In the absence of dual parity, my current method is to just make mirror copies of my most important data shares (pictures, documents, etc.) on different disks.  I manually update the mirrors about once per month.

Im sort of glad unraid forces the zeroing and reading of a drive before use.

 

That actually is not true.....

 

I was not clear. i meant preclearing the drive zeros and reads to make sure it is good to go.

 

Ugh at the thought of shoving an unformatted untested drive and pray for the best (and to be down for hours)

well now with the hard drives prices sky high ...

it would be a nice thing if Tom could grant us this request in the next beta ??

i am sure most of us have some smaller hard drives laying around that could be used for the moment till the bigger drives become affordable again ....

i myself am using all my slots but still have 3 x 500gb drives and 1 x 750 gb drive laying around (precleared them and ready for use ) that i would like to use before i run out of space...

 

dunno how hard it is to do this but i guess it is just changing a number somewhere ...

 

 

I know one of the betas made an adjustment towards this, but it's not functional at the current time.

I was just wondering if this is still on the road map as this topic is over 2 years old.

Beta and RC versions of UnRAID now support 23 data drives.  Please see "What is the difference between the unRAID licenses?"

Beta and RC versions of UnRAID now support 23 data drives.  Please see "What is the difference between the unRAID licenses?"

 

Thanks for that info.  Do you know if 2 parity drives are still on the development plan?

I would actually prefer a 22+2 than a 23+1.

Thanks for that info.  Do you know if 2 parity drives are still on the development plan?

I would actually prefer a 22+2 than a 23+1.

 

Only Tom would know what the UnRAID future holds.  He has said that, once v5.0 is finalized, he has several features ready to go, so I assume a new set of betas will arrive shortly after v5.0 final.