RAID options for Gluster

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.



[Index of Archives]     [Gluster Development]     [Linux Filesytems Development]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux