[Gluster-users] Kicking a stuck heal

[Dave Sherohman]

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.

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.

-- 
Dave Sherohman