Not quite. Losing one bit in one RAID stripe basically means you've lost all that stripe (due to the way RAID checksums work, the whole stripe will be marked as invalid). A typical stripe size is 64 kB, which must then be multiplied by the number of drives (minus one, for RAID-5). That will tell you how much data you've lost. If the total amount of data is smaller than one file system allocation unit, then you probably only lost one file (unless that part of the filesystem was compressed, wich can mean more than one file per allocation unit). If it was bigger, you may have lost more files.

Anyway, you are right that (unlike the ZDNet article claims) the risk is mainly to individual files (or small groups of files), not to the whole array.

That does change when you get up into the larger capacities and higher performances of products that aren't really aimed at home users, so I'm not saying RAID5 doesn't have any real uses. But for a typical home or small-office user, it's uneconomic.

To me, the more interesting question is, "Are we really going to lose the whole array if there's one unrecoverable section?" I don't know all the detailed mechanics of how RAID5 works, but that seems to me like it would require a remarkably boneheaded design. Most ordinary single-disk filesystems don't have this property, certainly. Even FAT filesystems usually have at least two copies of the allocation tables, or so I am told, and in practice a filesystem error is usually in a system file, which can be easily replaced because it's a standard part of the operating system and thus extremely non-unique. I would like to think that in the event the RAID controller cannot recover a certain sector from the drives, it would just return an error when attempting to read that sector, the same as an ordinary disk controller would do if a single drive could not recover the sector, and let the software figure out what to do about it, which in most cases would probably just mean marking the sector as bad and possibly corrupting one file. Perhaps someone who is more versed in RAID than I am can discuss this point. (And before someone asks what if the whole RAID is just used to store One Big File, that would probably be a database, and in that case wouldn't you use replication instead of RAID?)

I do think that RAID5 can sometimes be a false economy, depending on the amount of storage capacity you're talking about. Suppose you're talking about a three-drive RAID5 setup with a typical size of drive (in late 1998, we'll say 100GB, or maybe 150). By using RAID5 instead of RAID1, you get 2/3 of the total capacity instead of 1/2, which sounds like a win. But in a lot of cases it's probably a loss, because the three drives probably cost more than the two drives of greater capacity that you would need to get the same amount of storage out of RAID1. The simplicity of RAID1 is worth something, as well.

It is, of course, still no substitute for offsite backups. Any data you would still want in the event of a complete hardware failure of the entire computer should be backed up offsite. Fire, theft, lightning, malicious bogus anonymous tips to overzealous law enforcement, ... there any number of exciting ways you can lose all the computers in the building at one shot.

Au contraire! The coin was fair!

It's the *technique* that was not. *That's* about as random as juggling chainsaws.

It takes around 5 million tries to get the probability of at least one failure up to 95%.

The article claims this failure rate will lead to the DEATH of RAID, but wouldn't it be more likely to cause the LIFE of RAID? If a drive has a decent chance of corrupting 1 file every time you fill it up, wouldn't you want to put it into a RAID 5 even more than ever before?

As far as I know, unrecoverable read errors always happen after retry attempts. Sometimes the drive just can't figure out what that bit used to be. I think it's quite possible for the drive to then be able to successfully write and read data from that exact same location, though I presume it'll actually map that location out, probably replacing it with a sector from a section set aside for the purpose.