Let's talk about Raid-6

[Waseh]

Spinning the drives is a TINY price to pay for the HUGE advantage of dual fault tolerance 

 

^This!

 

I don't disagree, but if a solution exist where array spin up is not needed on write I do think that as worthwhile

 

I am not a specialist in this area - but short of implementing some sort of redundant cache (which was discussed earlier) or storing the writes in memory (now I am thinking outside of the box) what possible solution is there for not spinning up the drives to write in a stripe scenario? Perhaps if the stripe is implemented so not ALL drives have to be spun up. Isn't that what NewApp claims? Getting out of my depth here - but I cannot see how there is any solution to spinning up on write if there isn't an intermediate / cache. You've got to write to something right and to write to it (if its a HDD) it has to be spinning right? *shrugs*.

 

I see I might have expressed my self less than clear there - I simply mean retaining the functionality we have now where only the drive being written to (as well as parity disk/s) are spinning during write operations. Examining the licensing of one of the first two options mentioned in the first post would be very interesting in my opinion.

[gubbgnutten]

I am not a specialist in this area - but short of implementing some sort of redundant cache (which was discussed earlier) or storing the writes in memory (now I am thinking outside of the box) what possible solution is there for not spinning up the drives to write in a stripe scenario? Perhaps if the stripe is implemented so not ALL drives have to be spun up. Isn't that what NewApp claims? Getting out of my depth here - but I cannot see how there is any solution to spinning up on write if there isn't an intermediate / cache. You've got to write to something right and to write to it (if its a HDD) it has to be spinning right? *shrugs*.

 

The thing is, unRAID is not "a stripe scenario" like traditional RAID. One file goes to one disk, it's not split on block level to multiple disks. That's why we currently can write to the protected array and only have the parity disk and the actual disk(s) written to spinning, and that's the feature many of us cherish. Nobody is expecting to write to the array with all disks spun down.

 

As you can see in the first post, there are solutions for keeping this behaviour even with dual parity, but those pesky software patents are complicating things. I have no clue whatsoever about the licenses/royalties involved, but I can understand if LT in the end decides to steer clear in any case and stick with the safe method.

[SSD]

Another point that has not be explicitly stated - it is not like NetApp or IBM are actively soliciting "customers" like unRAID to use their patented technologies. In order to go in that direction, Tom would have to get lawyers involved and approach them about a possible agreement with a less than interested party. This could be potentially expensive and the outcome uncertain.

 

While I agree that having only 3 drives spin up for a write, (2 parity + data disk being written to), such a solution may be a non-starter. I'd rather see Tom implement using the publicly available option. Most of the changes he would make would be the same regardless of the algorithm, and if done properly, would enable the other solution to be added at a future date.

 

BTW, I do think "knocking on the door" to NetApp and maybe even IBM would be worthwhile to verify that they do not already have a licensing option available that Tom could use without the legal process. But if the answer comes back "no" - or it is prohibitively expensive - he should (IMO) move forward with the public solution.

[Clink]

For me, one drive redundancy during normal operation is fine - the likelihood of data loss due to fat fingers etc. is much higher than due to a drive failure (finger widths may vary).

 

However, replacing a drive or shrinking the array currently leave the array unprotected during the operation, unless one is happy to juggle cryptic 'dd' commands. The preclear script is already a great way to extend the array without losing parity protection, and I would love to see something similar, perhaps even fully integrated in the GUI, for the other array config changes. The aim would be to have one drive redundancy at all times.

 

[Waseh]

Another point that has not be explicitly stated - it is not like NetApp or IBM are actively soliciting "customers" like unRAID to use their patented technologies. In order to go in that direction, Tom would have to get lawyers involved and approach them about a possible agreement with a less than interested party. This could be potentially expensive and the outcome uncertain.

 

While I agree that having only 3 drives spin up for a write, (2 parity + data disk being written to), such a solution may be a non-starter. I'd rather see Tom implement using the publicly available option. Most of the changes he would make would be the same regardless of the algorithm, and if done properly, would enable the other solution to be added at a future date.

 

BTW, I do think "knocking on the door" to NetApp and maybe even IBM would be worthwhile to verify that they do not already have a licensing option available that Tom could use without the legal process. But if the answer comes back "no" - or it is prohibitively expensive - he should (IMO) move forward with the public solution.

 

Completely agree on this

[Ice_Black]

Correct me if I am wrong, as far I am aware unRAID does not have Real-time Mover? That would be cool feature.

 

Once a file has been copied to a cache and then instantly move to array.

[limetech]

I spent the weekend studying the math behind Raid-6 - learning Galois field algebra: now that's an exiting Saturday night!  It turns out there's no reason all data devices have to be spun up after all to recompute Q, and in fact read/modify/write of target data disk, P and Q disks should indeed be possible (even desirable in some cases).

 

In looking at linux md-layer again, yes indeed they do force reconstruct-write.  Time to start googling... It turns out there have been efforts in the past to introduce rmw for raid-6 "small write", even patch sets which didn't get merged.  Then, lo and behold, what got added in 4.1 kernel release?  That's right, rmw operation for raid-6!

 

Bottom line is that we should be able to incorporate this into the unraid flavor of md-driver.  It won't be a quick-and-dirty change however, since a lot of other code needs to be P+Q aware (such as user interface).

[Waseh]

I spent the weekend studying the math behind Raid-6 - learning Galois field algebra: now that's an exiting Saturday night!  It turns out there's no reason all data devices have to be spun up after all to recompute Q, and in fact read/modify/write of target data disk, P and Q disks should indeed be possible (even desirable in some cases).

 

In looking at linux md-layer again, yes indeed they do force reconstruct-write.  Time to start googling... It turns out there have been efforts in the past to introduce rmw for raid-6 "small write", even patch sets which didn't get merged.  Then, lo and behold, what got added in 4.1 kernel release?  That's right, rmw operation for raid-6!i

 

Bottom line is that we should be able to incorporate this into the unraid flavor of md-driver.  It won't be a quick-and-dirty change however, since a lot of other code needs to be P+Q aware (such as user interface).

 

That sounds amazing. Very good news Tom!

[garycase]

...  Galois field algebra: now that's an exiting Saturday night! 

 

Sounds like an excellent way to spend an evening !!  That, or perhaps a review of tensors 

... but then again I was always a bit of a math geek.  I was teaching tensors to grad students in physics when I was 17 

 

[garycase]

With read/modify/write embedded in the Linux kernel, it seems adding dual-parity is likely much closer than it had seemed.    Clearly there are still a bunch of implementation "details" that will take some time, but that's an encouraging sign.

 

Question for Tom:  Is this done in such a way that you can easily choose which parity model to use without extensive modifications to UnRAID?  i.e. will implementing dual parity REQUIRE dual parity, or will this be an easy-to-choose option?    Despite the significant boost in reliability, there will likely still be some who don't want to invest in the 2nd parity disk.

 

[gubbgnutten]

Bottom line is that we should be able to incorporate this into the unraid flavor of md-driver.  It won't be a quick-and-dirty change however, since a lot of other code needs to be P+Q aware (such as user interface).

 

Now that's a bottom line I like! 

 

My main server's array keeps growing, and dual parity should reduce my risk of data loss immensely. Yeah, I know, it is no replacement for backups, redundancy won't protect against deletions, bugs or overwriting the wrong file and so on...

 

I have backups of data I can't lose. Online, offline, offsite, you name it! Most data on the array does not fall into that category, however, but rather the "inconvenient to lose" category. Objectively speaking, the cost of losing everything in that category is less than the cost of having a proper backup of everything. Adding one more hard drive for parity on the other hand would be totally worth it.

[limetech]

With read/modify/write embedded in the Linux kernel, it seems adding dual-parity is likely much closer than it had seemed.    Clearly there are still a bunch of implementation "details" that will take some time, but that's an encouraging sign.

 

Question for Tom:  Is this done in such a way that you can easily choose which parity model to use without extensive modifications to UnRAID?  i.e. will implementing dual parity REQUIRE dual parity, or will this be an easy-to-choose option?    Despite the significant boost in reliability, there will likely still be some who don't want to invest in the 2nd parity disk.

 

Not required.  You will be able to choose whether to have P+Q or only P or even only Q.  The latter (Q but no P) is what would happen if P disk failed in a P+Q config.  Probably would not allow someone to configure a new array like this however (since it might be alot slower - that is t.b.d.).

 

Will also be able to utilize 'turbo-write' mode as well for P+Q configs.

[garycase]

Sounding good.  Personally I can't imagine why anyone would choose single parity -- especially if they don't have backups of their data -- but I'm sure there are some who don't want to spend the $$ to buy that extra disk.

 

The ability to enable turbo-write is also nice.    Between protected cache pools and a second level of fault tolerance, this is going to be a REALLY nice and compelling NAS solution.  ... with Dockers and VM's tossed in for dessert 

 

 

[vanstinator]

Super exciting news! When can we expect beta I kid I kid.

 

This would enable data integrity checking too, that would be a fun companion feature.

[limetech]

This would also enable data integrity checking too, that would be a fun companion feature.

 

Also triple-redundancy, P+Q+ I guess R?

[MisterWolfe]

Having a hot spare that automatically replaces a drive when it fails would be as/slightly more appealing to me than immediately implementing Raid 6.  Of course, both would be even better.

 

In the event of a drive failure it all boils down to time.  The sooner you get a replacement disk in place the better off you are.  If you're off site, that extra hour of travel could be responsible for data loss.

 

 

 

 

[archedraft]

Having a hot spare that automatically replaces a drive when it fails would be as/slightly more appealing to me than immediately implementing Raid 6.  Of course, both would be even better.

 

In the event of a drive failure it all boils down to time.  The sooner you get a replacement disk in place the better off you are.  If you're off site, that extra hour of travel could be responsible for data loss.

 

I'm just talking out of my butt here but I would have to imagine that this would be really hard to implement. There are quite a few ways that a drive can be thrown offline and there would need to be a lot of logic to have unRAID automatically figure out why you had a failed disk in the first place. You wouldn't want unRAID just to blindly start replacing a disk if in fact the disk is fine but maybe your PSU in being over utilized and that is the reason the drive red balled.

[JonathanM]

This would also enable data integrity checking too, that would be a fun companion feature.

 

Also triple-redundancy, P+Q+ I guess R?

Is any of this going to be unique enough to be patent worthy? It would be really cool to be in on the ground floor of something that could take over the home and small business server market. You could be the EMC of small servers.

[Kode]

Sounding good.  Personally I can't imagine why anyone would choose single parity -- especially if they don't have backups of their data -- but I'm sure there are some who don't want to spend the $$ to buy that extra disk.

 

Depends on the size of the array, 2 - 7 disks, double parity is probably overkill, once you get over that though it makes much more sense

[Helmonder]

I spent the weekend studying the math behind Raid-6 - learning Galois field algebra: now that's an exiting Saturday night!  It turns out there's no reason all data devices have to be spun up after all to recompute Q, and in fact read/modify/write of target data disk, P and Q disks should indeed be possible (even desirable in some cases).

 

In looking at linux md-layer again, yes indeed they do force reconstruct-write.  Time to start googling... It turns out there have been efforts in the past to introduce rmw for raid-6 "small write", even patch sets which didn't get merged.  Then, lo and behold, what got added in 4.1 kernel release?  That's right, rmw operation for raid-6!

 

Bottom line is that we should be able to incorporate this into the unraid flavor of md-driver.  It won't be a quick-and-dirty change however, since a lot of other code needs to be P+Q aware (such as user interface).

 

That is GREAT news !

[garycase]

Sounding good.  Personally I can't imagine why anyone would choose single parity -- especially if they don't have backups of their data -- but I'm sure there are some who don't want to spend the $$ to buy that extra disk.

 

Depends on the size of the array, 2 - 7 disks, double parity is probably overkill, once you get over that though it makes much more sense

 

Depends on the size of the disks.  With 6-8TB disks, you rapidly reach the likelihood of an unrecoverable bit error during a rebuild with even small arrays (5 disks or so).    On the other hand, with a small array it's also much easier to simply maintain a complete backup ... and if you're doing that, a single parity disk is fine, since even if you encounter a rebuild fault you can still recover from your backups.

 

[Helmonder]

Having a hot spare that automatically replaces a drive when it fails would be as/slightly more appealing to me than immediately implementing Raid 6.  Of course, both would be even better.

 

In the event of a drive failure it all boils down to time.  The sooner you get a replacement disk in place the better off you are.  If you're off site, that extra hour of travel could be responsible for data loss.

 

I'm just talking out of my butt here but I would have to imagine that this would be really hard to implement. There are quite a few ways that a drive can be thrown offline and there would need to be a lot of logic to have unRAID automatically figure out why you had a failed disk in the first place. You wouldn't want unRAID just to blindly start replacing a disk if in fact the disk is fine but maybe your PSU in being over utilized and that is the reason the drive red balled.

 

Exactly... I am guessing it would be EASY to implement an automatic disk failover.. Issue would be that you would get a lot of cases where that would happen without it beiing necessary..

 

However having the option would be nice... Just a simple button that would say "failover to spare disk" that would throw out the redball and activate the (down spinned) spare drive would still save time.. And very "wife friendly" when on the road..

[garycase]

Agree ... I think an automatic failover would be relatively easy to implement, but may in fact result in some drive replacements that weren't actually necessary.    On the other hand, I suspect that many of those "failures that aren't really failures" are due to movement of the server; changes where cables have been plugged/unplugged/bumped; etc. ... so in normal operations a failure is indeed likely a failure -- and as noted, it would have a very nice WAF 

[SSD]

Great news Tom! Excited to see unRaid-DP!

 

A question, after your study of the algorithm, will P+Q enable you to triangulate the cause of a parity error to a particular disk?

[BRiT]

I spent the weekend studying the math behind Raid-6 - learning Galois field algebra: now that's an exiting Saturday night!  It turns out there's no reason all data devices have to be spun up after all to recompute Q, and in fact read/modify/write of target data disk, P and Q disks should indeed be possible (even desirable in some cases).

 

In looking at linux md-layer again, yes indeed they do force reconstruct-write.  Time to start googling... It turns out there have been efforts in the past to introduce rmw for raid-6 "small write", even patch sets which didn't get merged.  Then, lo and behold, what got added in 4.1 kernel release?  That's right, rmw operation for raid-6!

 

Bottom line is that we should be able to incorporate this into the unraid flavor of md-driver.  It won't be a quick-and-dirty change however, since a lot of other code needs to be P+Q aware (such as user interface).

 

Excellent!