Why RAID 5 stops working in 2009 (2007)

It's like saying, "It's an outrage that this drink holds only 37 ounces! For this kind of money I expect it to hold at least 38 ounces. I would pay for that."

-

My 4 downvoters are clearly a lot worse at math at I am.

Let me spell it out for you:

"Reliability of 100000000000000 is unacceptable! I need exactly 1000000000000000 of reliability (a factor 10 difference only)."

If you don't see how that is funny, the problem is with you, not me. That's a hilariously specific, and small, change.

"Man, having a 30% chance of a bit flipping if I read 4 TB is unacceptable. I should have to read like...40 TB for a 30% chance of a bit flip!"

It's particularly funny because in the face of this being unacceptable, I would expect a solution, like error correction, that adds 5-10 orders of magnitude (many bit flips have to all happen in the same sector, by coincidence, at the already low 10^14 rate), for it to make it past the error correction layer.

The other thing is that given that we're talking about ERROR RATES, I cannot possibly believe that they have it down to such a specific number as 100000000000000. It would have to be a range. You should target more than 1 order of magnitude to get something more reliable (like ECC RAM versus regular RAM). [1]

Just like the error margin on 37 ounces must be like 37-40 ounces anyway.

[1] first reference I found: http://lambda-diode.com/opinion/ecc-memory-2

"I computed that if you have 4 GiB of memory, you have 96% chance of getting a bit flip in three days because of cosmic rays. SECDED ECC would reduce that to a negligible one chance in six billion." That is, for example, a change of

1 per 34359738368 bits (rounding 96% to 100%) to 1 per 206158430208000000000 bits (multiplying by 6 billion).

34359738368 bits is 10^10.

206158430208000000000 is 10^20.

That's the kind of change (give or take) that I was expecting parent to suggest - not one order of magnitude!

If this were the case, forums would be filled to the brim with ZFS users whinging about how they get CKSUM errors practically every time they scrubbed their pools. They do happen, but nothing like that frequently.

> That means hard disks can no longer be considered reliable devices that return the data written to them

They were never such devices in the first place if you ever valued your data enough to care. Even if your disks are perfect, your cabling, backplanes, IO controllers, drivers or memory probably aren't.

Slowly Btrfs on Linux and ReFS on Windows are becoming more prevalent. Since storage density is growing faster than most home users can use it, hopefully in the near future consumer computers will come configured to store multiple copies of their data. Instead of one day noticing that a picture is corrupted or the computer won't boot, periodicity scrubs will detect corruption before it's too late.

Though ZFS and Btrfs solve the unreadable bit problem with extent checksums, so you really don't need to worry about mechanical disks, yet. You would need two URE's in the same block to kill the checksumming.

Zero corruption, zero problems.

If you use Debian then install the debsums program which will do that for you for non-user data and report any errors.

You should also install mdadm and set it to check the array every month.

And finally install smartmontools and have it do a short self check every day and a long one (i.e. a full disk read) every week.

For most people it's better to make a nightly copy to other HD. Raid is for saving downtime on HD failures, doesn't save you from accidental rm -r, word processor corrupting your thesis, GPU driver crash corrupting your filesystem, box getting owned, etc.

But how does that help in the case of drive failure? If a drive fails, then as size increases won't the exposure to a URE also increase? Is it better than RAID5?

Edit: Apparently this is wrong. Read comments below