Re: Kicking a stuck heal

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On Fri, Sep 7, 2018 at 7:31 PM Dave Sherohman <dave@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxx> 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 +Keithley, Kaleb +Shyam 
 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@xxxxxxxxxxx
https://lists.gluster.org/mailman/listinfo/gluster-users


--
Pranith
_______________________________________________
Gluster-users mailing list
Gluster-users@xxxxxxxxxxx
https://lists.gluster.org/mailman/listinfo/gluster-users

[Index of Archives]     [Gluster Development]     [Linux Filesytems Development]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux