[Gluster-devel] 2 way with Arbiter degraded behavior

[Jeff Applewhite]

Yes thanks. That is exactly the scenario I was referring to.
Writes will never be optimizable in this way but in random workloads
the majority of IO's will usually be reads.

On Wed, Feb 21, 2018 at 11:39 AM, Manoj Pillai <mpillai at redhat.com> wrote:
>
>
> On Wed, Feb 21, 2018 at 9:13 PM, Jeff Applewhite <japplewh at redhat.com>
> wrote:
>>
>> Hi All
>>
>> When you have a setup with 2 way replication + Arbiter backed by two
>> large RAID 6 volumes what happens when there is a disk failure and
>> rebuild in progress in one of those RAID sets from a client
>> perspective?
>>
>> Does the FUSE client know how to prioritize the quicker disk (the RAID
>> set that is not in rebuild)?  If not could it be made smart in this
>> way? I ask because with large disks, rebuild priority could be set to
>> very fast on the controller card if Gluster can auto detect or in some
>> way work around the relatively slow performance from one of two
>> backends. The likelihood of having rebuilds in progress on two
>> different raid sets on two different servers is very low.
>>
>> Another way to state this is "is there some advantage we can gain from
>> having double replication (RAID 6 + Gluster file replication)?"
>>
>> Thanks,
>>
>>
>> Jeff Applewhite
>
>
> I opened an issue sometime back  with this and some other scenarios in mind:
> https://github.com/gluster/glusterfs/issues/363.
>
> -- Manoj
>
>> _______________________________________________
>> Gluster-devel mailing list
>> Gluster-devel at gluster.org
>> http://lists.gluster.org/mailman/listinfo/gluster-devel
>
>



-- 
Jeff Applewhite
Principal Product Manager