If you save a copy of the config folder after you stop the array with the old parity drive, then power down, replace the drive, and power up with the new to build it you can at any time power down, put the old config folder back, re-install/assign the old parity drive and re-start.  The array will not even know you had swapped out the old drive

 

I believe the mount operation alone causes a write to the filesystem's superblock.(at least it does with other file systems).

 

I believe that Joe's scenario would work.  The super.dat file is not updated on every boot - just on device configuration changes.

 

Even if there were some minor updates within the "housekeeping" area on the disk, I do not think a few sync errors would negatively impact reestablishing the array with the backup parity disk.

I'm not 100% sure... but I'm pretty sure you can't have 2 parity disks for 2 disk protection unless you want to stripe data across all the data disks.

 

RAID6 can rebuild from a 2 disk failure because it's able to compare data across all the drives in the array. Each disk has bits of of a file written to it and used with 2 parity disks it's able to gather the missing pieces.

 

But under unRAID, each disk has all the bits of a file written to one disk. When compared to parity it's only able to find the missing pieces in the event of 1 hard drive failure. I can't see how it would be possible to have a second parity drive cover you from 2 data disk losses. From everything I know about RAID setups, it's not possible unless data is stripped.

 

You could create a mirror copy (RAID1) of parity, but that would only save you from a parity failure... which is less likely then a data disk failure.

 

Currently the best setup is an unRAID server and you simply copy important files accross multiple data disks. This gives you multiple drive protection at the expensive of less total storage.

 

A RAID1 setup added to unRAID would make the process more seamless as you wouldn't need to copy an important file to 2 different disks manually. Simply add it to a share that is shared as a RAID1 setup, and unRAID will mirror that file across the 2 disks you choose. This would give you seamless 2 disk protection of your important files.

 

Reading through this thread and just thought I'd add a few thoughts ...

 

It makes NO difference if the data is striped or not in terms of data protection using (1) parity for single-failure protection and (2) Reed-Solomon coding for dual-failure protection.  The difference is stricly in how the error-correction bits are calculated.  A parity disk works fine for single-failure protection (whether the data is striped or not doesn't matter -- in terms of error correction UnRAID works EXACTLY the same way as RAID-5); but for protection against a 2nd failure you need more sophisticated math to correct the 2nd failed disk.  RAID-6 uses a variant of Reed Solomon coding to do this ... and UnRAID could too, if it should evolve to be tolerant of 2 failures.  Again, the math would be exactly the same as RAID-6 -- and it does NOT matter if the data is striped.  Remember ... from the perspective of these error-correcting algorithms, they're simply correcting a bitstream across multiple disks -- the file structure is irrelevant.

 

What IS true is that the Reed Solomon calculations are much more intensive than simple parity; so you'd want to have a better CPU than the minimal CPU's that are often used for UnRAID servers.    It could still work just fine -- remember, the CPU is dedicated to UnRAID, so that fact you need to use a high % of it for error calculations is essentially irrelevant.  In fact, Linux RAID supports RAID-6 already, and works quite well in this regard.

 

For those who are interested in the math for RAID-6, have a look at this:  http://www.kernel.org/pub/linux/kernel/people/hpa/raid6.pdf

Even if there were some minor updates within the "housekeeping" area on the disk, I do not think a few sync errors would negatively impact reestablishing the array with the backup parity disk.

 

Thanks for that link!  It is excellent and pretty easy to read and understand.  Very cool!

 

Not to keep beating a dead horse, but we've never seen a 2-drive failure scenario.  But we have seen scenarios where parity gets out-of-sync with data somehow (just today there was a post about someone with 117 unexplained parity errors).  The most frustating part is that when this happens you are pretty helpless in determining what disk / much less what file(s) are affected.  RAID-6 will not help with this.

Thanks for that link!  It is excellent and pretty easy to read and understand.  Very cool!

 

Maybe if you have a College Degree in math. 

I do!    But that was a long time ago.

 

Most Reed Solomon articles are pretty hard to follow.  Check out the wiki!  The referenced article is about the easiest to follow I've seen.

I'd like to add my support for addition of the 2 parity system... 

My biggest complaint is in upgrading the parity drive to a bigger one, you run the risk of being unprotected while it's being built.  (which could take many hours, right?)

Or you keep your old parity and don't use the system until it's done rebuilding the new parity disk.  So I either sacrifice reliablility or availibility.

I don't want to lose either!

 

For me, if we had the ability to build the 2nd parity disk while the first was still in the system, then I could upgrade my parity disk and keep my system on-line AND be protected.  After it's done building then I'd probably take the original one off-line and add it as a new drive.  But at least there is no down time or unprotected time.

 

Just my $0.02

I'm not against adding an option for a second parity drive, but I do think users should be aware of the downside, another significant hit on write performance.  Writing to a parity protected drive now takes about 2 to 3 times as long as reads do, because there are 4 disk I/O's involved in a write, only 1 I/O in a read.  Adding a second parity drive means adding a third drive to the equation, effectively causing 6 disk I/O's for each write.  I am going to speculate on write times dropping to about 2.5 to 4 times as long as reads.  And since this involves one more drive being buffered, it is possible that the stream delays to empty full buffers are going to be even more of a problem.  I don't think the slower writes are going to be acceptable to most users.

 

Just to add some perspective, I think we have gotten spoiled pretty quickly by the advantages of parity protection.  But we have probably grown up without missing it most of our lives.  An extremely small percentage of the drives we have ever used are parity protected or mirrored, certainly very few of the system drives in our desktops.  Very very few systems are sold today with mirrored or parity protected drives, although more and more are now capable of it.  We have expected our drives to either fail quickly, or give us years of reliable operation.  And we have relied on backups to save us when they do very unexpectedly fail.

 

Which brings me to the last point, parity protection is NOT a substitute for backups.  I would prefer more effort being put into backup procedures, and additional copies of our data, than improving the safety of any one copy of our data.  Please see the UnRAID Topical Index, Backups section (especially the later links) for more thoughts on backups.

 

One last thought, you can upgrade the parity drive to a larger drive, without endangering the current parity protection (but you can't keep the array online), by a manual procedure.

* disconnect the network cable (optional, but very recommended for safety)

* un-assign the current parity drive

* shut down, optionally disconnect or uninstall the parity drive, install the new parity drive

* boot, assign the new parity drive, and build parity

* if all successful, reconnect the network cable

If anything goes wrong while the new parity drive is being built, re-install the old parity drive, and do the Trust My Array procedure.

 

Edit:  just realized that Joe has already stated this idea about rebuilding the parity drive, and in a safer manner by saving and restoring the config folder.  Please see his post above.

I'm not against adding an option for a second parity drive, but I do think users should be aware of the downside, another significant hit on write performance.  Writing to a parity protected drive now takes about 2 to 3 times as long as reads do, because there are 4 disk I/O's involved in a write, only 1 I/O in a read.  Adding a second parity drive means adding a third drive to the equation, effectively causing 6 disk I/O's for each write.  I am going to speculate on write times dropping to about 2.5 to 4 times as long as reads.  And since this involves one more drive being buffered, it is possible that the stream delays to empty full buffers are going to be even more of a problem.  I don't think the slower writes are going to be acceptable to most users.

 

Well for me, It's only an issue when upgrading the parity drive. Myself, I would use only one parity drive all other times.  But also in my case.. I'm using a cache drive so write speed isn't important.

 

Just to add some perspective, I think we have gotten spoiled pretty quickly by the advantages of parity protection.  But we have probably grown up without missing it most of our lives.  An extremely small percentage of the drives we have ever used are parity protected or mirrored, certainly very few of the system drives in our desktops.  Very very few systems are sold today with mirrored or parity protected drives, although more and more are now capable of it.  We have expected our drives to either fail quickly, or give us years of reliable operation.  And we have relied on backups to save us when they do very unexpectedly fail.

True...  I agree that we have gotten a little spoiled..  But now that we have it, we are trying to be able to use it all the time.

 

Which brings me to the last point, parity protection is NOT a substitute for backups.  I would prefer more effort being put into backup procedures, and additional copies of our data, than improving the safety of any one copy of our data.  Please see the UnRAID Topical Index, Backups section (especially the later links) for more thoughts on backups.

 

UnRaid is where I store all my incremental backups! (along with my music and TV shows and DVDs)  Do I need a backup of my back up   probably not. 

 

One last thought, you can upgrade the parity drive to a larger drive, without endangering the current parity protection (but you can't keep the array online), by a manual procedure.

That's the problem..  I have to have the array offline for many hours while the new parity builds or risk being unprotected!