On 06/14/2012 09:33 AM, Marcus Bointon wrote: > On 14 Jun 2012, at 15:22, "Fernando Frediani (Qube)" > <fernando.frediani at qubenet.net> wrote: > >> Well, as far as I know the amount of IOPS you can get from a RAID 5/6 is >> the same that you get from a single disk. The write can not be >> acknowledged until it is written to all the data and parity disks. > > It can exceed that with battery back-up on the controller. Even without a BBU, a smart RAID 5/6 controller won't need to hit all of the disks for every write. It only needs to hit the disks for the blocks it's writing plus the parity disk for that stripe, and then it can calculate the new parity (RAID 5) as: new_parity = old_parity ^ (new_data ^ old_data) RAID 6 is a bit more complicated, but still possible, so you can get *some* parallelism across large RAID 5/6 sets. The problem is that creating larger sets means fewer of them per host. GlusterFS itself can often generate more parallelism across a larger number of smaller sets/bricks. This also tends to isolate the performance effects of a RAID rebuild to a subset of the total, at some cost in storage utilization.
