Bug 1453086
| Summary: | Brick Multiplexing: On reboot of a node Brick multiplexing feature lost on that node as multiple brick processes get spawned | ||
|---|---|---|---|
| Product: | [Community] GlusterFS | Reporter: | Samikshan Bairagya <sbairagy> |
| Component: | glusterd | Assignee: | Samikshan Bairagya <sbairagy> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | |
| Severity: | urgent | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 3.11 | CC: | amukherj, bugs, nchilaka, rhinduja, rhs-bugs, storage-qa-internal |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | brick-multiplexing | ||
| Fixed In Version: | glusterfs-3.11.0 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | 1451248 | Environment: | |
| Last Closed: | 2017-05-30 18:53:12 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: | 1451248, 1453087 | ||
| Bug Blocks: | 1450889 | ||
|
Description
Samikshan Bairagya
2017-05-22 06:13:34 UTC
REVIEW: https://review.gluster.org/17351 (glusterd: Don't spawn new glusterfsds on node reboot with brick-mux) posted (#1) for review on release-3.11 by Samikshan Bairagya (samikshan) COMMIT: https://review.gluster.org/17351 committed in release-3.11 by Shyamsundar Ranganathan (srangana) ------ commit 671dfcd82f6a7c56fbcbfde33cba22c0b585a046 Author: Samikshan Bairagya <samikshan> Date: Tue May 16 15:07:21 2017 +0530 glusterd: Don't spawn new glusterfsds on node reboot with brick-mux With brick multiplexing enabled, upon a node reboot new bricks were not being attached to the first spawned brick process even though there wasn't any compatibility issues. The reason for this is that upon glusterd restart after a node reboot, since brick services aren't running, glusterd starts the bricks in a "no-wait" mode. So after a brick process is spawned for the first brick, there isn't enough time for the corresponding pid file to get populated with a value before the compatibilty check is made for the next brick. This commit solves this by iteratively waiting for the pidfile to be populated in the brick compatibility comparison stage before checking if the brick process is alive. > Reviewed-on: https://review.gluster.org/17307 > Reviewed-by: Atin Mukherjee <amukherj> > Smoke: Gluster Build System <jenkins.org> > NetBSD-regression: NetBSD Build System <jenkins.org> > CentOS-regression: Gluster Build System <jenkins.org> (cherry picked from commit 13e7b3b354a252ad4065f7b2f0f805c40a3c5d18) Change-Id: Ibd1f8e54c63e4bb04162143c9d70f09918a44aa4 BUG: 1453086 Signed-off-by: Samikshan Bairagya <samikshan> Reviewed-on: https://review.gluster.org/17351 Smoke: Gluster Build System <jenkins.org> NetBSD-regression: NetBSD Build System <jenkins.org> CentOS-regression: Gluster Build System <jenkins.org> Reviewed-by: Atin Mukherjee <amukherj> REVIEW: https://review.gluster.org/17383 (glusterd: Eliminate race in brick compatibility checking stage) posted (#1) for review on release-3.11 by Samikshan Bairagya (samikshan) COMMIT: https://review.gluster.org/17383 committed in release-3.11 by Shyamsundar Ranganathan (srangana) ------ commit 71752f1bde9e8ad7a71670c885279f91ff951a1b Author: Samikshan Bairagya <samikshan> Date: Tue May 23 19:32:24 2017 +0530 glusterd: Eliminate race in brick compatibility checking stage In https://review.gluster.org/17307/, while looking for compatible bricks for multiplexing, it is checked if the brick pidfile exists before checking if the corresponding brick process is running. However checking if the brick process is running just after checking if the pidfile exists isn't enough since there might be race conditions where the pidfile has been created but hasn't been updated with a pid value yet. This commit solves that by making sure that we wait iteratively till the pid value is updated as well. > Reviewed-on: https://review.gluster.org/17375 > Smoke: Gluster Build System <jenkins.org> > Reviewed-by: Atin Mukherjee <amukherj> > NetBSD-regression: NetBSD Build System <jenkins.org> > CentOS-regression: Gluster Build System <jenkins.org> (cherry picked from commit a8624b8b13a1f4222e4d3e33fa5836d7b45369bc) Change-Id: Ib7a158f95566486f7c1f84b6357c9b89e4c797ae BUG: 1453086 Signed-off-by: Samikshan Bairagya <samikshan> Reviewed-on: https://review.gluster.org/17383 Smoke: Gluster Build System <jenkins.org> Reviewed-by: Atin Mukherjee <amukherj> 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.11.0, please open a new bug report. glusterfs-3.11.0 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/announce/2017-May/000073.html [2] https://www.gluster.org/pipermail/gluster-users/ |