----- Original Message -----From: "Zhang Huan" <zhanghuan@xxxxxxxxxxx>
To: "Raghavendra G" <raghavendra@xxxxxxxxxxx>
Cc: "GlusterFS Maintainers" <maintainers@xxxxxxxxxxx>, "Gluster Devel" <gluster-devel@xxxxxxxxxxx>, "Kaushal Madappa"
<kmadappa@xxxxxxxxxx>
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@xxxxxxxxxxx > 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. 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@xxxxxxxxxx > wrote:
On 05/28/2017 09:24 AM, Atin Mukherjee wrote:
On Sun, May 28, 2017 at 1:48 PM, Niels de Vos < ndevos@xxxxxxxxxx
<mailto: ndevos@xxxxxxxxxx >> 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@xxxxxxxxxxx <mailto: maintainers@xxxxxxxxxxx >
http://lists.gluster.org/mailman/listinfo/maintainers
< http://lists.gluster.org/mailman/listinfo/maintainers >
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://lists.gluster.org/mailman/listinfo/gluster-devel
--
Raghavendra G
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://lists.gluster.org/mailman/listinfo/gluster-devel
_______________________________________________
maintainers mailing list
maintainers@xxxxxxxxxxx
http://lists.gluster.org/mailman/listinfo/maintainers
|
