[Gluster-devel] [Gluster-Maintainers] Backport for "Add back socket for polling of events immediately..."

Wed May 31 00:44:56 UTC 2017

> On 30 May 2017, at 19:58, Raghavendra Gowdappa <rgowdapp at redhat.com> wrote:
> 
> 
> 
> ----- Original Message -----
>> From: "Zhang Huan" <zhanghuan at open-fs.com <mailto:zhanghuan at open-fs.com>>
>> To: "Raghavendra G" <raghavendra at gluster.com <mailto:raghavendra at gluster.com>>
>> Cc: "GlusterFS Maintainers" <maintainers at gluster.org <mailto:maintainers at gluster.org>>, "Gluster Devel" <gluster-devel at gluster.org <mailto:gluster-devel at gluster.org>>, "Kaushal Madappa"
>> <kmadappa at redhat.com <mailto:kmadappa at redhat.com>>
>> Sent: Tuesday, May 30, 2017 3:33:09 PM
>> Subject: Re: [Gluster-Maintainers] [Gluster-devel] Backport for "Add back socket for polling of events
>> immediately..."
>> 
>> 
>> 
>> 
>> On 29 May 2017, at 11:16, Raghavendra G < raghavendra at gluster.com > wrote:
>> 
>> Replying to all queries here:
>> 
>> * Is it a bug or performance enhancement?
>> Its a performance enhancement. No functionality is broken if this patch is
>> not taken in.
>> 
>> * Are there performance numbers to validate the claim?
>> https://bugzilla.redhat.com/show_bug.cgi?id=1358606#c9
>> 
>> * Are there any existing users who need this enhancement?
>> https://bugzilla.redhat.com/show_bug.cgi?id=1358606#c27
>> 
>> Though not sure what branch Zhang Huan is on. @Zhang your inputs are needed
>> here.
>> 
>> We are currently on 3.8. Thus the performance number is based on 3.8.
>> If you need more details, please let me know.
> 
> Thanks Zhang. The question was more on the lines whether you need backport of the fix to 3.8.

Actually, we really need this backported to 3.8. I have seen the backport of it to 3.8.
https://review.gluster.org/#/c/15046/ <https://review.gluster.org/#/c/15046/>
Once it gets merged, we will rebase to it and test it as a whole.

> Can you upgrade to recent releases (say 3.11.x or 3.10.x)?

Sorry, I am afraid not. Gusterfs is one of the key components in our product. An upgrade alone would break the whole thing. 

> 
>> 
>> 
>> 
>> 
>> 
>> * Do I think this patch _should_ go into any of the released branches?
>> Personally, I don't feel strongly either way. I am fine with this patch not
>> making into any of released branches. But, I do think there are users who
>> are affected with this (Especially EC/Disperse configurations). If they want
>> to stick to the released branches, pulling into released branches will help
>> them. @Pranith/Xavi, what are your opinions on this?
>> 
>> regards,
>> Raghavendra
>> 
>> On Sun, May 28, 2017 at 6:58 PM, Shyam < srangana at redhat.com > wrote:
>> 
>> 
>> On 05/28/2017 09:24 AM, Atin Mukherjee wrote:
>> 
>> 
>> 
>> 
>> On Sun, May 28, 2017 at 1:48 PM, Niels de Vos < ndevos at redhat.com
>> <mailto: ndevos at redhat.com >> wrote:
>> 
>> On Fri, May 26, 2017 at 12:25:42PM -0400, Shyam wrote:
>>> Or this one: https://review.gluster.org/15036 <
>>> https://review.gluster.org/15036 >
>>> 
>>> This is backported to 3.8/10 and 3.11 and considering the size and impact
>>> of
>>> the change, I wanted to be sure that we are going to accept this across all
>>> 3 releases?
>>> 
>>> @Du, would like your thoughts on this.
>>> 
>>> @niels, @kaushal, @talur, as release owners, could you weigh in as well
>>> please.
>>> 
>>> I am thinking that we get this into 3.11.1 if there is agreement, and not
>>> in
>>> 3.11.0 as we are finalizing the release in 3 days, and this change looks
>>> big, to get in at this time.
>> 
>> 
>> Given 3.11 is going to be a new release, I'd recommend to get this fix
>> in (if we have time). https://review.gluster.org/#/c/17402/ is dependent
>> on this one.
>> 
>> It is not a fix Atin, it is a more fundamental change to request processing,
>> with 2 days to the release, you want me to merge this?
>> 
>> Is there a *bug* that will surface without this change or is it a performance
>> enhancement?
>> 
>> 
>> 
>> 
>>> 
>>> Further the change is actually an enhancement, and provides performance
>>> benefits, so it is valid as a change itself, but I feel it is too late to
>>> add to the current 3.11 release.
>> 
>> Indeed, and mostly we do not merge enhancements that are non-trivial to
>> stable branches. Each change that we backport introduces the chance on
>> regressions for users with their unknown (and possibly awkward)
>> workloads.
>> 
>> The patch itself looks ok, but it is difficult to predict how the change
>> affects current deployments. I prefer to be conservative and not have
>> this merged in 3.8, at least for now. Are there any statistics in how
>> performance is affected with this change? Having features like this only
>> in newer versions might also convince users to upgrade sooner, 3.8 will
>> only be supported until 3.12 (or 4.0) gets released, which is approx. 3
>> months from now according to our schedule.
>> 
>> Niels
>> 
>> _______________________________________________
>> maintainers mailing list
>> maintainers at gluster.org <mailto: maintainers at gluster.org >
>> http://lists.gluster.org/mailman/listinfo/maintainers
>> < http://lists.gluster.org/mailman/listinfo/maintainers >
>> 
>> 
>> _______________________________________________
>> Gluster-devel mailing list
>> Gluster-devel at gluster.org
>> http://lists.gluster.org/mailman/listinfo/gluster-devel
>> 
>> 
>> 
>> --
>> Raghavendra G
>> _______________________________________________
>> Gluster-devel mailing list
>> Gluster-devel at gluster.org
>> http://lists.gluster.org/mailman/listinfo/gluster-devel
>> 
>> 
>> _______________________________________________
>> maintainers mailing list
>> maintainers at gluster.org <mailto:maintainers at gluster.org>
>> http://lists.gluster.org/mailman/listinfo/maintainers <http://lists.gluster.org/mailman/listinfo/maintainers>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/gluster-devel/attachments/20170531/ba931e11/attachment.html>