[Gluster-users] Kicking a stuck heal
Pranith Kumar Karampuri
pkarampu at redhat.com
Mon Sep 10 07:28:04 UTC 2018
On Fri, Sep 7, 2018 at 7:31 PM Dave Sherohman <dave at sherohman.org> wrote:
> On Fri, Sep 07, 2018 at 10:46:01AM +0530, Pranith Kumar Karampuri wrote:
> > On Tue, Sep 4, 2018 at 6:06 PM Dave Sherohman <dave at sherohman.org>
> wrote:
> >
> > > On Tue, Sep 04, 2018 at 05:32:53AM -0500, Dave Sherohman wrote:
> > > > Is there anything I can do to kick the self-heal back into action and
> > > > get those final 59 entries cleaned up?
> > >
> > > In response to the request about what version of gluster I'm running
> > > (...which I deleted prematurely...), it's the latest version from the
> > > Debian stable repository, which they identify as 3.8.8-1.
> > >
> >
> > Hey, 3.8.8-1 is EOL, is it possible to use upstream version that is
> > maintained like 3.12.x or 4.1.x?
>
> I prefer to stick with the Debian stable releases because they are
> **STABLE**. Backported fixes for security issues, and that's it. No
> new features to introduce new bugs, no incremental changes that just
> happen to break backwards compatibility in the process.
>
+de Vos, Niels <ndevos at redhat.com> +Keithley, Kaleb <kkeithle at redhat.com>
+Shyam <srangana at redhat.com>
Does Debian community do any feature/stability testing for glusterfs to
make sure that the releases are more stable than the releases the gluster
community does? Do you guys know? As far as I understand the deb packages
from stable branches of glusterfs are included in the release?
> We currently are using an upstream elasticsearch because of an
> application which requires features that aren't in deb-stable. As part
> of the same server move that led to my question here, we also had our
> elasticsearch cluster go down because, when the servers rebooted, a
> version incompatibility with one of the es plugins prevented it from
> starting back up. I don't want that happening with our disks. I want
> something that I know works today and will continue to work tomorrow,
> even if a security patch comes out between now and then.
>
>
> If gluster upstream has a "security fixes and critical bugfixes ONLY,
> never a single new feature" version available, then point me at it and
> I'd be comfortable switching to that, but if it's the usual "Security
> fix? Just upgrade to the latest and greatest new version!", then I'd
> really rather not. That model works (more or less...) for end-user
> software, but I don't want it anywhere near my servers.
>
I'm afraid the answer is no. I personally fixed at least 1 bug which
prevents stuck heal/dead-lock issue which went in 3.10 release (Even though
the description of the bug says arbiter, we found it to be a generic bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1401404) which also has new
features. Let us wait for answers from Shyam/Niels/Kaleb to find if Debian
community does indeed something to make the releases more stable than the
releases that happen in the community (as far as I understand it doesn't).
May be that may convince you to re-consider your stance about the upgrade
to one of the active stable releases on gluster and then we can see if you
still face the problem and we could help fix it in further releases.
>
> --
> Dave Sherohman
> _______________________________________________
> Gluster-users mailing list
> Gluster-users at gluster.org
> https://lists.gluster.org/mailman/listinfo/gluster-users
>
--
Pranith
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/gluster-users/attachments/20180910/721dda0c/attachment.html>
More information about the Gluster-users
mailing list