Hi,

I was really just curious after reading Backblaze's new blog post about their Storage Pod 4.0. I will never personally do it, but what if someone wanted to use on of those at home? unRAID has a drive limit of 25. If you either built/ordered the redundant model, you could have 45 data drives, and in the redundant boot drive spots you could put your parity/cache disks. Is there any reason unRAID doesn't support more than 25? Is it a limitation that's there for a good reason or is it just arbitrary? If there's a reason behind it, forgive my lack of knowledge.

 

If anyone wants to read the article, http://blog.backblaze.com/2014/03/19/backblaze-storage-pod-4/

Is there any reason unRAID doesn't support more than 25?

Yes, to support more than 26 total /dev/sd? devices, you have to move to the /dev/sd?? naming, and at the moment, that would require a substantial rewrite of code. There are plenty more high value features that are ahead of expanding drive numbers, like diagonal parity. Also, would you really want 45 drives with only 1 failure tolerated? That's an awful lot of data to put at risk.

Is there any reason unRAID doesn't support more than 25?

Yes, to support more than 26 total /dev/sd? devices, you have to move to the /dev/sd?? naming, and at the moment, that would require a substantial rewrite of code. There are plenty more high value features that are ahead of expanding drive numbers, like diagonal parity. Also, would you really want 45 drives with only 1 failure tolerated? That's an awful lot of data to put at risk.

You could make it so you have 2 or 3 parity drives for it. But I understand now why it wasn't done.

Instead of pushing higher in number of drives, could it be possible instead to push to integrate multiple servers? Such as having one be master with others being slaves?

Therefore you keep the same structure, increase redundancy, reduce energy consumption, etc.

I guess one can't redirect connections though, so it would cut down transfer speeds from the slave if it has to go through the master.

What about the option for 2 or 3 parity drives? Will that ever be done? Reasons against it?

Tom said previously that he wants to add multiple drive parity. He also questioned about having UNRAID master/slave machines so he's had the thought.

What about the option for 2 or 3 parity drives? Will that ever be done? Reasons against it?

 

There has been scant discussion.

 

So called "diagonal parity" may be the best solution, but comes with an extra licensing cost to Tom.

 

A second parity, using an algorithm similar to RAID-6, would require all drives to be spun up to do a write to the array.

 

Either would have some performance penalty, but not awful.

 

And then there is the need to have a second drive of the largest capacity that is dedicated to redundancy and not storing data.

 

[soapbox]

It is funny, but the second parity disk is a very desired feature (for some good reasons), but the truth is 99% of the issues we have seen in the forums have nothing to do with a second failed disk. It is caused by users shooting themselves in the foot because they don't understand what to do in failure scenarios, and when an issue occurs they read the wiki and immediately spring into action doing the wrong things and making an easily recoverable situation into a fricking mess. Would the second parity help in some of these situations? Maybe it would help in some situations. But even more effective would be having users read the support forums for a month and follow some of the more complex recovery cases. There are not very many scenarios, and understanding them is not so tough. Ask questions if you don't understand the advice given. It won't take long until you can survive most of the common scenarios. And I would advise users that have a failure and think they know what to do, to post the steps they plan to follow and ask for confirmation before proceeding. And what ever you do, if you are swapping a disk out of service, even if you think it has failed and is unusable - DO NOT preclear, reformat or discard that disk until recovery is 100% complete! 80% of the time recovery from stupid mistakes requires getting that disk kicking again, which is almost always possible.

[/soapbox]

 

That's my $0.02 on dual parity.

... but the truth is 99% of the issues we have seen in the forums have nothing to do with a second failed disk. It is caused by users shooting themselves in the foot because they don't understand what to do in failure scenarios ...

 

The benefit of dual parity has little to do with protecting against a 2nd failure.  It primary provides two major benefits:  (1) When a parity error is detected, it's possible to compute exactly where the error is; and (2) when a drive does fail, the system remains fault tolerant during the rebuild -- so a 2nd failure during a rebuild doesn't cause a failed rebuild.

 

Those are MAJOR benefits in improving the overall UnRAID reliability.

 

The benefit of dual parity has little to do with protecting against a 2nd failure.  It primary provides two major benefits:  (1) When a parity error is detected, it's possible to compute exactly where the error is; and (2) when a drive does fail, the system remains fault tolerant during the rebuild -- so a 2nd failure during a rebuild doesn't cause a failed rebuild.

 

Those are MAJOR benefits in improving the overall UnRAID reliability.

+1 Im sold

 

Sent from my SCH-I605 using Tapatalk

 

 

... but the truth is 99% of the issues we have seen in the forums have nothing to do with a second failed disk. It is caused by users shooting themselves in the foot because they don't understand what to do in failure scenarios ...

 

The benefit of dual parity has little to do with protecting against a 2nd failure.  It primary provides two major benefits:  (1) When a parity error is detected, it's possible to compute exactly where the error is; and (2) when a drive does fail, the system remains fault tolerant during the rebuild -- so a 2nd failure during a rebuild doesn't cause a failed rebuild.

 

Those are MAJOR benefits in improving the overall UnRAID reliability.

 

This becomes more so with the newer large drives. 6TB drive is going to take quite a while to rebuild increasing risk something fails during the rebuild.

Plus do you really need more than 24x6TB

Josh

... but the truth is 99% of the issues we have seen in the forums have nothing to do with a second failed disk. It is caused by users shooting themselves in the foot because they don't understand what to do in failure scenarios ...

 

The benefit of dual parity has little to do with protecting against a 2nd failure.  It primary provides two major benefits:  (1) When a parity error is detected, it's possible to compute exactly where the error is; and (2) when a drive does fail, the system remains fault tolerant during the rebuild -- so a 2nd failure during a rebuild doesn't cause a failed rebuild.

 

Those are MAJOR benefits in improving the overall UnRAID reliability.

 

Feeling a bit misquoted. I did say ...

 

"... the second parity disk is a very desired feature (for some good reasons)"

 

(Note the first one you list (honing in on parity errors) has never been communicated by Tom, and may or may not be implemented.)

 

One more important point, unRAID is undergoing significant enhancement around virtualization, an idea that seemingly popped up over night. We've been discussing dual parity for at least 4 years and it hasn't happened yet. So even if dual parity were some kind of miracle cure for all user errors (which it is not) - it isn't coming any time soon IMO.

 

So I still stand by my premise. Most users are inexperienced in telling if a problem is really a disk problem at all, and are too quick to "just try stuff" after hunting through the forums or wiki. A little learning is worth way more than the second parity disk (which isn't even available).

 

Parity errors caused by bad drives are extremely extremely rare (maybe never).  Drive failures while rebuilding a failed drive - extremely extremely rare (one confirmed case since I've been here, and that is 8 years). Users shooting themselves in the foot? Happens all the time. Recently we had three such incidents occurring at the same time.

 

So do yourself a favor and learn a little more. It is free and more likely to save your data than the second parity disk, which will absolutely not be free.

 

Cheers!

Drive failures while rebuilding a failed drive - extremely extremely rare (one confirmed case since I've been here, and that is 8 years).

 

Actually this is not only common, but in fact statistically fairly likely with modern high-capacity drives. It may be rare in your experience -- but it is COMMON with very large arrays.    That's the #1 reason most corporate users have migrated to RAID-6 arrays instead of RAID-5 ... and statistically that's exactly what we're talking about with migrating UnRAID to dual parity.

 

With smaller arrays -- a modest number of disks and/or relatively small disks -- the likelihood of a failure during rebuild is indeed fairly small; but with a large array of 3-4TB drives the probability of a failure during rebuild gets well about 50%.

 

Drive failures while rebuilding a failed drive - extremely extremely rare (one confirmed case since I've been here, and that is 8 years).

 

Actually this is not only common, but in fact statistically fairly likely with modern high-capacity drives. It may be rare in your experience -- but it is COMMON with very large arrays.    That's the #1 reason most corporate users have migrated to RAID-6 arrays instead of RAID-5 ... and statistically that's exactly what we're talking about with migrating UnRAID to dual parity.

 

With smaller arrays -- a modest number of disks and/or relatively small disks -- the likelihood of a failure during rebuild is indeed fairly small; but with a large array of 3-4TB drives the probability of a failure during rebuild gets well about 50%.

 

Generally with raid 5 all drives are purchased at the same time , which might make multiple drive failures in a short period of time more likely.

 

Sent from a mobile device, sorry for any typos.

 

 

It is funny, but the second parity disk is a very desired feature (for some good reasons), but the truth is 99% of the issues we have seen in the forums have nothing to do with a second failed disk.

 

Your sample is "issues seen in the forum".  That is a self selected population.

 

I've had multiple drive failures... I didn't report it in the forum because I know the answer, and took care of it myself.

 

I won't deploy unRAID in several client situations because of lack of dual parity.

 

With drive sizes skyrocketing (and outpacing ECC advances), the likelihood of a read error in a rebuild increases.  Then you WILL have some forum issues   Realize a lot of people are buying the cheapest high-GB drives, not enterprise quality, and their ECC ratios to drive size are decreasing to what I consider dangerous territory.

 

Bit rot - for the same reasons w/r/t drive sizes increasing relative to ECC ability to correct errors.

 

The ability to identify and map where a parity error comes from.  That to me is a very basic diagnostic tool.

 

As for the DP licensing, it should be a separate optional feature, so the incremental cost of that feature covers the cost.

It is funny, but the second parity disk is a very desired feature (for some good reasons), but the truth is 99% of the issues we have seen in the forums have nothing to do with a second failed disk.

 

Your sample is "issues seen in the forum".  That is a self selected population.

 

I've had multiple drive failures... I didn't report it in the forum because I know the answer, and took care of it myself.

 

I won't deploy unRAID in several client situations because of lack of dual parity.

 

With drive sizes skyrocketing (and outpacing ECC advances), the likelihood of a read error in a rebuild increases.  Then you WILL have some forum issues   Realize a lot of people are buying the cheapest high-GB drives, not enterprise quality, and their ECC ratios to drive size are decreasing to what I consider dangerous territory.

 

Bit rot - for the same reasons w/r/t drive sizes increasing relative to ECC ability to correct errors.

 

The ability to identify and map where a parity error comes from.  That to me is a very basic diagnostic tool.

 

As for the DP licensing, it should be a separate optional feature, so the incremental cost of that feature covers the cost.

 

Are you saying the dumb things users do is not a greater risk than dual disk failures?

Are you saying the dumb things users do is not a greater risk than dual disk failures?

 

Risk to whom?  You can spend unlimited resources trying to make something idiot proof, and the only result will be better idiots finding new ways to be idiots.

 

There is a point of diminishing returns in attempts at idiotproofing.  Don't set a goal of being idiotproof... set a coal of intuitive usability with a rich feature set. 

Are you saying the dumb things users do is not a greater risk than dual disk failures?

 

Risk to whom?  You can spend unlimited resources trying to make something idiot proof, and the only result will be better idiots finding new ways to be idiots.

 

There is a point of diminishing returns in attempts at idiotproofing.  Don't set a goal of being idiotproof... set a coal of intuitive usability with a rich feature set.

 

I agree.

 

But my message here is not to Limetech - it is to unRAID users. Users that should strive to not be idiots. Because unRAID is not idiot proof.

Drive failures while rebuilding a failed drive - extremely extremely rare (one confirmed case since I've been here, and that is 8 years).

 

I don't agree with this, Perhaps reported, and/or requested for assistance.

I had this occur simply because of a pending sector, which is why I'm an advocate for the webGui to notify people.

In fact I posted a thread about my recovery using ddrescue to try and recapture the data I was able to save.

 

Users shooting themselves in the foot? Happens all the time. Recently we had three such incidents occurring at the same time.So do yourself a favor and learn a little more. It is free and more likely to save your data than the second parity disk, which will absolutely not be free.

 

I agree 100% with this sentiment.  Perhaps the answer is a good FAQ on what to do in various scenarios. (Which is why I posted a thread on dd_rescue)

 

After that a scheduled badblocks monthly review of each drive alongside a SMART long test.

While I could do this, it's pointless without some kind of monitor and alert environment.

 

For me Dual parity is not my answer. It's being informed of impending problems.

For others, Dual parity is going to be a live saver if it's a drive failure without filesystem corruption issue or an informing mechanism if a drive is starting to reveal issues.

Which is why I have said for a long time, Lime should concentrate on 1) a stable, open, extensible platform and 2) features that can't be done by others (like 64-bit, DP, encryption, support for other filesystems, notification hooks, etc.)  Anything not a core functionality ought to be a proving ground for devs.

 

Plugin devs can do a lot of the rest.  There is so much that can be done by third parties... some small, and some big, like a php-based webGUI for configuring and managing VMs for example.  Perhaps a bounty system for devs for the best addons.  Tom drew from others for parts of the new webGUI.... no reason that paradigm can be repeated.  Pay some bounties for apps.  If an app Lime needs doesn't appear, spec the app that is wanted, and let it out for "bid."

 

But to tie this back into the OP, you are fscking insane to run 25+ spinners with a single parity drive.  That's about as safe as using 20 year old condoms.

 

 

... I had this occur simply because of a pending sector, which is why I'm an advocate for the webGui to notify people.

 

Absolutely agree with notifications !!    Even if we had dual parity, it does no good if there's not some notification of a failure so a rebuild can be initiated while there's still a fault-tolerant array.

 

 

... you are fscking insane to run 25+ spinners with a single parity drive.  That's about as safe as using 20 year old condoms.

 

Agree.  With 25 spinners the probability of a 2nd failure during a rebuild is VERY high ... with 4TB consumer-class drives it's actually more likely than not.

 

... There is, I suppose, one disadvantage of dual parity => the "I don't need backups" folks are even more likely to feel that's the case.    It is, of course, less likely that they'll be needed ... but no matter how fault-tolerant a RAID array might be, it is NOT a backup 

Well at least we got the band back together. And feisty as ever!

 

Weebo - for the record you were the one example of a dual drive failure.

 

But you guys are all smoking something if you are arguing that users are frequently encountering the limits of unRaid's redundancy. Can it happen? Yes. Does it get more likely as drives get bigger and magnetic media gets more dense? Yes. But more dangerous is the user that overreacts to a red ball and finds himself three days later and with the help of an expert, trying to recover his data from a simulated disk with reiserfsck because he screwed up his array so bad. If you disagree post some links to users that lost data due to dual drive failures (or a bad sector during a recovery) with unRaid. Weebo is one - I accept that. How about a few more? And I'll post some links to episodes like the one I just listed.

 

Update: check out this post very consistent with support reauests. Doesn't know the difference between a disk check and a disk recovery!

 

HERE

 

Hope he learns the difference soon.

Well at least we got the band back together. And feisty as ever!

 

Weebo - for the record you were the one example of a dual drive failure.

 

But you guys are all smoking something if you are arguing that users are frequently encountering the limits of unRaid's redundancy. Can it happen? Yes. Does it get more likely as drives get bigger and magnetic media gets more dense? Yes. But more dangerous is the user that overreacts to a red ball and finds himself three days later and with the help of an expert, trying to recover his data from a simulated disk with reiserfsck because he screwed up his array so bad. If you disagree post some links to users that lost data due to dual drive failures (or a bad sector during a recovery) with unRaid. Weebo is one - I accept that. How about a few more? And I'll post some links to episodes like the one I just listed.

 

There was another guy that I helped offline use DD rescue to recover from a dual drive failure. I think the forum is getting too big (or I'm too lazy) to search for it.

 

There have not been been many dual drive failure cases I can remember.

There certainly has been many OMG I destroyed my data cases.

 

I do remember a number of, I keep getting parity errors, where are they coming from cases.

Just to get back to the original question in this thread ...

 

Is there any reason unRAID doesn't support more than 25? Is it a limitation that's there for a good reason or is it just arbitrary? If there's a reason behind it, forgive my lack of knowledge.

 

There are two reasons for the limit:

(1)  UnRAID currently doesn't support dual letter drive designations

(2)  It's already very risky to have a 25 drive array with only single parity -- this would be MUCH worse with any significant increase in the number of drives.

 

 

There certainly has been many OMG I destroyed my data cases.

 

1) That's THEIR fault. 

2) That same thing happens in every platform.

3) Nothing unRAID could have done within reason to help them.

 

That's not to say we don't help them when it happens and caution them about such carelessness in the future.... but it isn't unRAID's fault.

 

If you want to throw up more "WARNING WILL ROBINSON" boxes when idiots click on things, then so be it, but they will click right through them without reading.  I *know* ... I've written those apps and had it happen.

 

Consider the --yes-i-know-what-i-am-doing flag ... never stopped an idiot from killing a drive... it is useless except for commandline typos.