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@xxxxxxxxxx> wrote: > > > On Wed, Feb 21, 2018 at 9:13 PM, Jeff Applewhite <japplewh@xxxxxxxxxx> > 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@xxxxxxxxxxx >> http://lists.gluster.org/mailman/listinfo/gluster-devel > > -- Jeff Applewhite Principal Product Manager _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://lists.gluster.org/mailman/listinfo/gluster-devel
