Re: [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  wrote:
>
>
> On Wed, Feb 21, 2018 at 9:13 PM, Jeff Applewhite 
> 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@gluster.org
>> http://lists.gluster.org/mailman/listinfo/gluster-devel
>
>



-- 
Jeff Applewhite
Principal Product Manager
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] 2 way with Arbiter degraded behavior

[Manoj Pillai]

On Wed, Feb 21, 2018 at 9:13 PM, Jeff Applewhite 
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@gluster.org
> http://lists.gluster.org/mailman/listinfo/gluster-devel
>
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

[Gluster-devel] 2 way with Arbiter degraded behavior

[Jeff Applewhite]

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
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel