prevent bit rot (bit flip) with RAID6 and regular consistency checks ?

  • 592 Views
  • Last Post 31 August 2016
  • Topic Is Solved
m e posted this 19 August 2016

Hi,

I'm about to buy the R6 and plan to put in RAID6 configuration with double parity.

Please correct me if I'm wrong, but such setup should be almost immune to bit rot right ?

The main purpose of the device will be photo collection storage so I'm particularly sensitive about the bit rot issue.

To my understanding with dual parity I'll have 3 versions of the data, when one of them gets corrupted the scheduled consistency check should be able to fix it by looking at the other two.

I presume it's very unlikely that bit flip would happen in the same place in two of the three versions. 

I'd really appreciate if someone could correct me if there's a flow in this reasoning.

Kind Regards

Marcin

 

 

Order By: Standard | Latest | Votes
Joe Engledow posted this 19 August 2016

Dual parity means you can lose two drives and still keep going with 100% of the data. It's not three copies; but rather the parity data is written to 2 adjacent drives rather than 1.

Regular redundancy checks will ensure that the parity data matches the main data. It will not prevent the corruption you describe but it will make it less likely.

No storage method is perfect and incorruptible... at least not yet.

m e posted this 20 August 2016

Thanks for a very quick answer, 

yes true, i don't know what i was thinking about :). parity info is not the same as the data itself. Even with two different parities (RAID6) you may not know which chunk of data fliped.

 

Jerry Lin posted this 21 August 2016

RAID5 is enough.

The best way to protect data is buy more storage devices.(RAID or single drive is fine).

And manual backup into different device and  different locations.

 

 

m e posted this 31 August 2016

Just wanted to follow up on the topic, I had a bit of time and dived into the raid schemes a bit more.
@Joe Engledow: I agreed to early with you :).

So here's the thing, lets think of raid6 as n+2 disks, 2 for parities and n for data. the first parity is computed on rows, the second on diagonals. for simplicity both are XORs. Assuming that there's only a single bit flip happening at a time, one can identify where exactly the bit was flipped, that place is the intersection of the row parity inconsistency and diagonal parity inconsistency.

My question is then still not answered :), does pegasus offers bitrot correction with raid6 during disk consistenty checks?

Best

Joe Engledow posted this 31 August 2016

“Bit rot” is a term in programming. In the storage media industry, we use Data Degradation, which we work to combat with maintenance like the Media Patrol and Redundancy Check.

The wiki article says “Magnetic Media may experience data decay as bits lose their magnetic orientation. Periodic refreshing by rewriting the data can alleviate this problem."

So it may occur - or it may not. It is so rare that we don’t design systems with that in mind - just provide the RC process to run the check if needed. Billions of storage systems exist and nobody is worried about that rot - it isn't lurking.

This is true of older magnetic media, but the current disk technology is more advanced and less susceptible to this than ever before.

Joe Engledow posted this 31 August 2016

Bit rot as you portray it is not an issue. Every block on your hard drive is heavily checksummed. When a block is read the checksum is compared to what was calculated when the block was written and if there is a bit error the drive will correct it. Hard disk ECC can correct for multiple bit errors, it is not just a checksum. If there is too much damage to correct then the drive will report a bad block. So silent bit-flip per se is not something that there is any realistic concern about. And that's on the individual drive level, before you even put them into groups with RAID.

Regarding RAID-6, the parity stripes are normally calculated with 2 different methods, XOR and Reed-Solomon (check the Wikipedia page). This is known as P+Q. You can see the encoding scheme in the verbose logical drive information. 

In both cases redundancy check will recalculate the parity and compare it with the parity stripe. If you run RC with the ‘repair’ option and  the parity read is different, then the parity will be re-written to match what was read from the data.

As a side benefit: since every block in the logical drive will be read, the drive will have a chance to re-write blocks with correctable checksum errors silently, and blocks that have gone bad will be detected and re-mapped to working blocks. 

m e posted this 31 August 2016

Hi, Thanks again for a very quick reply. 
Sure there are multiple ways to compute the second parity, Reed-Solomon of course, but row-diagonal xor could be used too. I guess the more important is the fact that's one parity is based on rows and the other on diagonals probably with any method (?)

I know there's drive level ECC, but let's put it aside. the error rate of modern desktop disks is 10^14 blocks (SAS 10^16), which (for desktop drives) is not that unfrequent when the array is 12-24 TB. These days RAID5 doesn't really offer much security from failure, during a rebuild after a disk failure it's not that uncommon to hit a bad block on another disk (http://www.zdnet.com/article/why-raid-6-stops-working-in-2019/)

But now back to the raid6, you wrote that during the RC check with the 'repair' option the parity would be re-written. Maybe I'm missing something but wouldn't it make sense to do correct the data using the double parity. in case you can really identify where exactly the change occured.

cheers

Search
Categories
Close