That's not RAID5, that's RAID4.
From the bottom of page: This page was last updated on 26 Mar 2016.
Disk storage had gotten cheap enough, fast enough, for RAID-1 to be sufficient for my organization's storage needs. We've briefly flirted with RAID-5, but it proved troublesome.
> OK here is the deal, RAID5 uses ONLY ONE parity drive per stripe
In RAID-6 you have multiple redundancy, so the probability of complete failure can be arbitrarily reduced. However, most people go with RAID-5 because they haven't got enough disks for RAID-6 to make sense, whereas if you have loads (like Backblaze for instance using 3 parity out of 15 disks) then it does make sense.
So is RAID0.
>negative consequences when it comes to performance (write amplification)
If you're using SSDs, not really a concern with spinning rust.
Really? I've successfully rebuilt literally thousands of RAID5 arrays successfully over the years, with maybe a two dozen failing over that time period, and in most of those cases the rebuilds were not kicked off shortly after the initial disk failure. (I used to work in the hosting industry. Many a customer opted for RAID5 in the servers they leased from us)
I've opted for RAIDZ3 at home, and don't know that I would recommend anything under RAID6, but I think it's pretty silly to claim that recovery is unlikely.
>If you're using SSDs, not really a concern with spinning rust.
This is not true. Raid5 has the same problem with "you must write a unit of x at once" that SSD have. If I've got a 64K chunk size on your raid5, assuming that the disk has been written to, if you are writing a whole 64K chunk, you are good. but if I'm writing a 32K chunk to a stripe that already has data (and you have the same 'I wrote the data and deleted it but maybe my underlying block doesn't know that it's deleted' problem you have with ssd) you need to read all the data in that chunk you want to keep, recalculate parity (the fast part) and then write that whole 64K chunk back out. It really is a lot like the problems you have with SSD, raid or no, only you have more choice over the chunk size when building the array.
All that said, I have also managed a lot of raid5 on spinning disk in my day... it absolutely screams for read-only workloads, and write back caching can usually mitigate the write amplification issues (of course, adding in more data consistency issues when you lose power) and while yeah, there is danger of losing a few sectors during rebuild, people also leave the hardware write back caches enabled on their disks. Given the choice, I'd trust data on a raid5 over data on disks with write-back cache enabled in your typical 'unexpected power loss every three years' situation. Either way, technically, yeah, it's not 100% safe, but most of the time it's good enough if you need the performance per dollar.
I think 'recovery (unlikely)' means a problem during recovery is unlikely.
I think RAID 3/4/5 can be better that nothing, they're not completely worthless, but come with significant down sides compared to better schemes that make them undesirable these days. The I in RAID was put there back when disks were many orders of magnitude more expensive than today, it's just a false economy not going to RAID10 or some other better scheme.