Let's talk about Raid-6

[BRiT]

What technology does unRaid's competition use ?

 

Anyone care to answer his question, it would be nice to know.

 

Netapp uses their netapp tech.

Ibm uses their ibm tech.

Others likely wont say what tech they use, at least its quite difficult to find anything other than "we use raid6" statements on the non industrial product offers.

 

Emc Symmetrix DMX raid6 was quite easy to find details on, but its likely too dense for most to follow other than they use a form of diagnol parity.

 

Sun and HP use P+Q, where Q is typically based on Error Correcting Code that is stripped across all disks.

[SSD]

What technology does unRaid's competition use ?

 

Anyone care to answer his question, it would be nice to know.

 

For RAID6 - the fact that it does or does not need to spin all of the disks is irrelevant. RAID arrays stripe the data, so all disks are spinning as data is being read or written. I would say that Reed Soloman is likely behind all of these types of algorithms, but with tweaks to provide certain characteristics.

 

HERE is a link to a high-level describing how NetApp's diagonal parity works.

 

I suppose a third option for Tom would be to write a Reed Soloman variant to implement diagonal parity. My understanding is that you can't copyright an idea, only an implementation of that idea.

[vanstinator]

Another thought, how long do the patents have left? At some point they have to expire. I didn't find anything in my cursor Google search.

[Griz]

I don't think cost is limetech's main objection, it's the dealing with lawyers part that is objectionable, and rightly so!

 

Another thought, how long do the patents have left? At some point they have to expire. I didn't find anything in my cursor Google search.

 

December 2022 if this is the only patent involved: http://www.google.com/patents/EP1324200A2?cl=ko

 

 

[SirMaster]

What about Field Theory?

 

Galois Field GF(2^ and a Cauchy matrix.

 

Detailed explanation, references, and working implementation here for 6 levels of parity: 

https://github.com/amadvance/snapraid/blob/master/raid/raid.c

 

FlexRAID claims infinite levels of parity according to the dev, but it's closed source.

 

ZFS does 3 levels of parity and the implementation can be found in OpenZFS: 

https://github.com/zfsonlinux/zfs/blob/master/module/zfs/vdev_raidz.c

 

ZFS uses the standard Reed Solomon Coding that is also mentioned about in the SnapRAID link as well as MDADM for it's double and for ZFS for it's triple parity.

 

Either way, some good info in the comment sections to these files and implementation examples if a similar approach is chosen so thought it was worth linking.

[TSM]

I'd pay for Raid-6 regardless of how it's implemented, as long as the cost is not to extravagant 

 

And as long as it's a feature you can turn on and off.  If the end user has a choice of whether they want to run with dual parity or not, and it's understood what the drive spin up implications are for each scenario.  Then whatever.  Limetech should implement the one they think will work the best. 

 

For people that use cache drives it's just a once a day thing anyway. 

 

[PeterB]

If a royalty is payable, I would see the addition of multiple parity as an additional unRAID license level, above Pro (Pro-plus?).

 

Like several others here, I would be prepared to pay an extra $30, or so, for one of the patented solutions.

 

Don't forget that if royalties are on a per end user license basis, the patent holder will expect to see a verifyable record of sales, or even to have control over the lecensing process.

[Alex.vision]

I also like the idea of dual parity vs multiple smaller arrays. Hard drives are only getting bigger, so even if we break down the array in to multiple smaller ones the mtbf rate becomes more and more prevalent. You could argue bigger drives and less of them, but with today's multimedia edging into 4K my 11 4tb disks would be filling up fast even if they were 8tb disks. If I have the space I'm filling it

I have an unused pro license and I would still be willing to pay an additional license fee for dual parity.  I can certainly understand the hesitancy of needing royalties and lawyers and the big mess that entails, but I think it would be worth it.  Just my 2 cents. 

[Helmonder]

My unraid file storage has become more and more important over the years, yes I use it mainly for media storage, but it would be a hell of a job to redownload (err.. "rip") all of that media again.. A lot of it would not be available any more.

 

I have made sure I have online backups for my personal video / kids photos and documents. But for the bulk I have chosen not to backup. It simply is to much data and I do not want to make the investment in another unraid box at distance.

 

I state the above because I do not want to trigger another "parity is not a backup battle", I know this and have made my own choice.

 

Concluding: I would be willing to pay for dual parity. Spinning up all drives is manageable, it does sound more "clean" to do it one of the other ways..

[garycase]

... I have made sure I have online backups for my personal video / kids photos and documents. But for the bulk I have chosen not to backup. It simply is to much data and I do not want to make the investment ...

 

I state the above because I do not want to trigger another "parity is not a backup battle", I know this and have made my own choice.

 

This is always a personal choice.  I advise everyone that backups are simply insurance ... and as with any other insurance, you should only insure what you can't afford or aren't willing to lose.    As for those who, like you, choose to not backup their data, that's an even more compelling case for using a system that can tolerate more than a single failed drive.

 

 

[Ice_Black]

To have all the disks spin up is defeating the purpose of having a unRAID license IMO.

 

I would be happy pay extra for a dual parity feature 

[danioj]

+1

 

It doesn't sound like a desirable situation to have all drives spun up for a write BUT for Dual Fault Tolerance FOR ME it would be worth it. BUT then I think about my reality, and really that reality is that I currently run my mover every hour anyway as I have not implemented a fault tolerant cache pool as yet (and leaving data on the cache drive for up to 24 hours is undesirable to me). So a high rate of spin up / down for writes is something I experience now anyway. 

 

As others have already noted the implementation of btrfs Cache Pool (with this feature or not) will allow me to reduce my mover back to once per day and it seems this would almost be mandatory with Dual Fault Tolerance. In summary - spin up doesn't bother me.

 

I personally would prefer Dual Fault Tolerance to the multi array feature.

 

As for implementation, I would prefer you choose the BEST option available. My 2c is that NetApp seems to implement what we want with less demand on the drives than the others - but that is a layman's interpretation of what appears to be one of the big differences. In any case, no matter what you choose I wouldn't mind paying an amount for an upgrade for v7 with Dual Fault Tollerance.

 

Why don't you guys cost up, get quotes and then come up with a model. Like I have said in previous posts about this feature I wouldn't mind contributing to my license fee "up front" if required to help the project get going.

 

P.S. Even talking about Dual Fault Tolerance for v7 is exciting! 

[kegler]

As disk sizes continue to grow, resulting in parity sync/check times are becoming unwieldy.  Barring some major breakthrough in disk access/write times, things are not likely to improve.  Our arrays are growing faster than our ability to run parity sync/check disk rebuild operations faster. 

 

StevenD, not pick on you specifically, but since you have a 48TB array, how long does it take you to do a parity check now? (or anyone else with a large array)  Parity operations with dual parity are going to be even slower.  NetApp claims that their system only incurs a 2% penalty using their dual parity. 

 

http://community.netapp.com/t5/Tech-OnTap-Articles/Back-to-Basics-RAID-DP/ta-p/86123

 

"The RAID-DP implementation within Data ONTAP is closely tied to the NetApp NVRAM and NetApp WAFL® (Write Anywhere File Layout). This is the key to the exceptional performance achieved by RAID-DP versus other RAID 6 implementations."

 

While they may license their dual parity for others to use, I suspect they will not license aspects of their implementation that give them that speed advantage.  At least not at a reasonable price.  I hope I am wrong.

 

We can debate single vs dual parity but selection of what to use is dependent on your array size, data type, backup practices not to mention the value you place or don't place on your data.  Trying to say one is better than the other will result in an endless debate. Everyone has to make their own call and live with the result.

 

In my opinion, I think the ability to subdivide large arrays into sub arrays is JUST AS IMPORTANT as implementing dual parity and needs to be part of the solution.

 

Sure dual parity protecting 20+ data disk WILL give you BETTER protection than single parity.  The question is "Is that enough?" I wouldn't want to protect mission critical data that way, but that's me.

 

It was not that long ago 3TB drives were considered big.  Now they are considered small.  When you start replacing those 3TB drives with 6, 8 or 10TB drives, how long will a disk rebuild take then?  We will soon be talking in terms of days rather than hours.  Array sizes are going to increase, not because you should, but because you can.

 

 

[SSD]

As disk sizes continue to grow, resulting in parity sync/check times are becoming unwieldy.  Barring some major breakthrough in disk access/write times, things are not likely to improve.  Our arrays are growing faster than our ability to run parity sync/check disk rebuild operations faster. 

 

The speed of parity checks and rebuilds has more to do with the largest disk, and less to do with the overall capacity. A parity check or rebuild of a single disk with a 48T array of 6+1 8T drives is going to be slower than one of 12+1 4T drives.

 

I think this is getting off topic.

 

By and large, I think there is general agreement that dual parity is valuable even if it requires full array spinup to do a write.

 

The cache pool is going to give users an ability to reduce the frequency of full spinups.

 

The speed issue is not going to be significant.

 

In my opinion, I think the ability to subdivide large arrays into sub arrays is JUST AS IMPORTANT as implementing dual parity and needs to be part of the solution.

 

Sure dual parity protecting 20+ data disk WILL give you BETTER protection than single parity.  The question is "Is that enough?" I wouldn't want to protect mission critical data that way, but that's me.

 

I do not agree. Subdividing can be achieved today with VMs. Dual parity is a brand new feature and given limited development time, I believe should be the priority.

[garycase]

... In my opinion, I think the ability to subdivide large arrays into sub arrays is JUST AS IMPORTANT as implementing dual parity and needs to be part of the solution.

 

You can effectively "sub-divide" your array already by simply defining shares with different sets of included drives.  And if the array had dual parity, that would provide all of those "sub-divided" storage units with dual fault tolerance.

 

 

Sure dual parity protecting 20+ data disk WILL give you BETTER protection than single parity.  The question is "Is that enough?" I wouldn't want to protect mission critical data that way, but that's me.

 

So you get BETTER protection for data ... what's the downside of that ??    As for "Is that enough?" ==> of course not.  You still need backups ... but that's true whether your array is tolerant of one, two, three, or even more failures.

 

 

[WeeboTech]

As disk sizes continue to grow, resulting in parity sync/check times are becoming unwieldy.  Barring some major breakthrough in disk access/write times, things are not likely to improve.  Our arrays are growing faster than our ability to run parity sync/check disk rebuild operations faster. 

 

The speed of parity checks and rebuilds has more to do with the largest disk, and less to do with the overall capacity. A parity check or rebuild of a single disk with a 48T array of 6+1 8T drives is going to be slower than one of 12+1 4T drives.

 

This is highly dependant on architecture of the motherboard/controllers and drives.

However, given that, using the values obtained by smart, chances are a rebuild and/or check will not be much faster then the SMART 'Extended self-test routine recommended polling time'

 

I think this is getting off topic.

You can blame me, but I'm sure someone would have brought it up.

However, food for thought, if Tom thought this was easy to obtain, he might suggest this for the time being.

 

By and large, I think there is general agreement that dual parity is valuable even if it requires full array spinup to do a write.

One of the most requested features, so I would have to agree here

 

The cache pool is going to give users an ability to reduce the frequency of full spinups.

and here as well.

 

The speed issue is not going to be significant.

This remains to be seen unless someone has actual experience with raid5 and raid6 numbers on linux.

In turbo write mode, writing to a single drive, the numbers will probably be very good. 

Chances are, if all drives have to be spinning, there could be a penalty.

 

In my 4 drive array with turbo write. If I started to access the other drives in the array simultaneously, write and read speed would drop significantly, Therefore a cache drive would probably be more important.

 

In my opinion, I think the ability to subdivide large arrays into sub arrays is JUST AS IMPORTANT as implementing dual parity and needs to be part of the solution.

 

Sure dual parity protecting 20+ data disk WILL give you BETTER protection than single parity.  The question is "Is that enough?" I wouldn't want to protect mission critical data that way, but that's me.

 

I do not agree. Subdividing can be achieved today with VMs.

At the cost of an additional license key.

 

Dual parity is a brand new feature and given limited development time, I believe should be the priority.

Agreed and possibly at some kind of upgrade fee to make the development effort worthwhile and/or pay any royalties.

 

While I think being able to subdivide arrays into smaller protected units is a great feature, the most requested feature has been multiple  parity drives.  snapraid has it, flexraid has it. unRAID needs it.

 

What smaller arrays give you is the ability to confine arrays to a 5x3 or a controller.

Compartmentalize your data and/or utilize turbo write for high speed writes.

 

I'm enamored with this methodology. In fact, so much, that instead of building one large server, I built multiple microservers.

instead of \\unraid\video, \\unraid\music \\unraid\images \\unraid\data \\unraid\backups

I went with \\video \\music \\images \\data \\backups

 

When I take down one to upgrade the drives, I do not affect the other.

 

Given all of that, I don't care how it's implemented at this point in time.

If a method to reduce number of spinning drives requires royalties, I'll certain contribute to the cause even if I don't plan to use it.

[ohlwiler]

Dual parity has been my most wanted feature for at least five years. Spinning up all drives is a small price to pay.

 

The ability to correct data in the event of a single error as bjp999 pointed out is a huge feature. This could be used during parity check time to correct the data instead of upgrade the parity. A few times in my unRAID history parity checks have indicated errors. I've always wondered if I had a file that got corrupted (most likely) or if somehow the parity drive was the error. Presently if parity and the data disks are not in sync there is no way to know who the culprit is, the parity or one of the data disks. Dual parity would make the ambiguity go away.

 

Depending on where the data is written, not all disks are required to be spun up. If the array is comprised of say 2T and 4T disks and the new data is written to the upper half of a 4T drive then only the 4T drives will need to be spun up. Careful array management would make that the norm.

[uldise]

Hi, just my 2c

i'm not seeing everyone about what RAID we are talking about: real-time on snapshot

OK, according to Tom's first post, RAID6 is a real-time one, but unRAID currently implements both variants - writing to disk share is real-time, to cached user share it's more snapshot if you don't have a cache pool..

 

so, if you think in terms of snapshot where mover runs once(or twice..) a day, and all disks are up, then you must have an option to define more than dual parity - SnapRAID have maximum of six now..

 

BTW, have anyone tried combine unRAID with SnapRAID for additional parity? with VMs it's possible now i think...

 

EDIT: thanks Trurl, corrected

[trurl]

... writing to disk share is real-time, to cached user share it's more snapshot if you don't have a cache pool...

FTFY

[TheDragon]

I would definitely be more than happy to pay extra for #1 or #2.

 

On a more general note I would love to see his feature, and would definitely use it myself

[Waseh]

This is definitely very interesting and a feature I have hoped to see for some time. I do however appreciate the ability to not spin up the entire array for write operations and would be more than willing to pay to preserve this feature with dual parity.

[garycase]

Since reads still don't require more than the drive being accessed to spin up, I don't think it really matters if you need to spin up all drives for writes to the array.    A lot of us didn't previously use cache drives due to the unprotected nature of cached data; but with a cache pool this concern goes away, so it's no big deal to cache your writes and just let Mover do the actual writes to the array once/day ... or you can click "Move Now" if you're writing a lot and want to clear the cache out.

 

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

 

[SSD]

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

 

^This!

[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

[danioj]

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*.