>>negative consequences when it comes to performance (write amplification) >If you're using SSDs, not really a concern with spinning rust. This is not true.

>>negative consequences when it comes to performance (write amplification) >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.