Taking a look at
http://en.wikipedia.org/wiki/Standard_RAID_levels#RAID_5 is instructive, particularly the section on RAID5 performance. It doesn't completely enumerate the issue with read-modify-write, although I have read detailed technical breakdowns elsewhere, but it does give a feel for it. Essentially, say you wanted to increment a counter in a database, the steps you would need to take are:
Read that entry from disk
Increment it in memory
Write the entry back to disk (atomic transaction)
Sequential write to transaction log
Read all data blocks plus parity block in that stripe
Calculate new parity block value once transaction entry is written
Write transaction log entry
Write new parity block
Random write to database
Read all data blocks plus parity block in that stripe
Calculate new parity block value once db entry is updated
Write db entry
Write new parity block
End process
If this was on an 6 disk RAID5, it would correlate to 17 soft I/O operations to the disk surface. A similar RAID10 would correlate to 5 such operations, moreover, the number increases which each disk added to a RAID5, it remains the same when increasing a RAID10.
Also, note the article compares with RAID0 - which for read purposes is the same or slower than RAID10 (because you can read multiple sequential or random pieces of data from multiple channels and disks simultaneously) - and it indicates that RAID5 is "slightly slower". For write performance in clearly indicates that it is dramatically slower (sometimes by as much as "an order of magnitude"). And mentions a group I had never heard of! BAARF - Battle Against Any RAID Five. An organisation I would have been a card carrying member of had they existed and I had been aware of them back in my DB days!!
