Bug 1399989
Summary: | [Disperse] healing should not start if only data bricks are UP | ||
---|---|---|---|
Product: | [Community] GlusterFS | Reporter: | Ashish Pandey <aspandey> |
Component: | disperse | Assignee: | Ashish Pandey <aspandey> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | |
Severity: | high | Docs Contact: | |
Priority: | unspecified | ||
Version: | 3.9 | CC: | aspandey, bugs, nchilaka, pkarampu, rhs-bugs, storage-qa-internal, tdesala |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | glusterfs-3.9.1 | Doc Type: | If docs needed, set a value |
Doc Text: | Story Points: | --- | |
Clone Of: | 1399072 | Environment: | |
Last Closed: | 2017-03-08 08:37:19 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | 1396010, 1399072 | ||
Bug Blocks: |
Description
Ashish Pandey
2016-11-30 08:32:57 UTC
REVIEW: http://review.gluster.org/15974 (cluster/ec: Healing should not start if only "data" bricks are UP) posted (#1) for review on release-3.9 by Ashish Pandey (aspandey) COMMIT: http://review.gluster.org/15974 committed in release-3.9 by Pranith Kumar Karampuri (pkarampu) ------ commit 63c6eafac95fbeb126fbc168933f4f204ea0a0ec Author: Ashish Pandey <aspandey> Date: Mon Nov 28 13:42:33 2016 +0530 cluster/ec: Healing should not start if only "data" bricks are UP Problem: In a disperse volume with "K+R" configuration, where "K" is the number of data bricks and "R" is the number of redundancy bricks (Total number of bricks, N = K+R), if only K bricks are UP, we should NOT start heal process. This is because the bricks, which are supposed to be healed, are not UP. This will unnecessary eat up the resources. Solution: Check for the number of xl_up_count and only if it is greater than ec->fragments (number of data bricks), start heal process. >Change-Id: I8579f39cfb47b65ff0f76e623b048bd67b15473b >BUG: 1399072 >Signed-off-by: Ashish Pandey <aspandey> >Reviewed-on: http://review.gluster.org/15937 >Reviewed-by: Xavier Hernandez <xhernandez> >Smoke: Gluster Build System <jenkins.org> >CentOS-regression: Gluster Build System <jenkins.org> >NetBSD-regression: NetBSD Build System <jenkins.org> >Signed-off-by: Ashish Pandey <aspandey> Change-Id: I8579f39cfb47b65ff0f76e623b048bd67b15473b BUG: 1399989 Signed-off-by: Ashish Pandey <aspandey> Reviewed-on: http://review.gluster.org/15974 Smoke: Gluster Build System <jenkins.org> Reviewed-by: Xavier Hernandez <xhernandez> NetBSD-regression: NetBSD Build System <jenkins.org> CentOS-regression: Gluster Build System <jenkins.org> This bug is getting closed because a release has been made available that should address the reported issue. In case the problem is still not fixed with glusterfs-3.9.1, please open a new bug report. glusterfs-3.9.1 has been announced on the Gluster mailinglists [1], packages for several distributions should become available in the near future. Keep an eye on the Gluster Users mailinglist [2] and the update infrastructure for your distribution. [1] http://lists.gluster.org/pipermail/gluster-users/2017-January/029725.html [2] https://www.gluster.org/pipermail/gluster-users/ |