3 ms·
The analysis in this article is horrifically poor. Among other things, just using the expected error rate as a pass/fail criterion is not a good idea. Even if
by apenwarr 12y ago
The analysis in this article is horrifically poor. Among other things, just using the expected error rate as a pass/fail criterion is not a good idea. Even if the "typical" RAID5 array doesn't fail, isn't it still bad if 1/10 or 1/100th of them fail because of randomness in the error distribution?
There are also lots of ways to mitigate this problem even with a high error rate. In particular, if you get a bad sector, don't just kick the disk immediately out of the RAID; try recovering that one sector first, using the other disks in the RAID. The drive's built-in sector remapping should then bypass the newly-bad sector.
I wrote about this in detail in 2008: http://apenwarr.ca/log/?m=200809#08 http://apenwarr.ca/log/?m=200809#08
- baruch 12y agoWhat you describe is what is known as disk scrubbing, and indeed if you are operating a RAID device and it doesn't do disk scrubs every so often you are doing it wrong. Linux mdadm has this feature as well and in most distributions that I'm aware of disk scrubbing is performed once a month by default. In addition, the reading into the BER and the immediate conclusion that RAID stands no chance is not quite correct. If you did your disk scrubs your disks are mostly clean and the likelyhood of failure is not that great. I was responsible for tens of thousands of disks in a storage system that did do disk scrubs and it did find occasionally a bad sector[1] and I've never even once seen a double failure as is often warned about in the "RAID is dead" articles. Please do your disk scrubs to avoid sectors falling off and remember that RAID is not backup, extra redundancy is still needed if you really care for your data. [1] I didn't have the sense of mind to compare the rate of error detection to the official BER.