Bug 1453087
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.10 | CC: | amukherj, bugs, nchilaka, rhinduja, rhs-bugs, rtalur, storage-qa-internal |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | brick-multiplexing | ||
Fixed In Version: | glusterfs-3.10.3 | Doc Type: | If docs needed, set a value |
Doc Text: | Story Points: | --- | |
Clone Of: | 1451248 | Environment: | |
Last Closed: | 2017-06-06 06:08:56 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 | ||
Bug Blocks: | 1450889, 1453086, 1457513 |
Description
Samikshan Bairagya
2017-05-22 06:18:01 UTC
REVIEW: https://review.gluster.org/17352 (glusterd: Don't spawn new glusterfsds on node reboot with brick-mux) posted (#1) for review on release-3.10 by Samikshan Bairagya (samikshan) COMMIT: https://review.gluster.org/17352 committed in release-3.10 by Raghavendra Talur (rtalur) ------ commit 1a90d86296f6529423a4450bc1e0b3bb12e4f0a2 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: 1453087 Signed-off-by: Samikshan Bairagya <samikshan> Reviewed-on: https://review.gluster.org/17352 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> Reviewed-by: Raghavendra Talur <rtalur> REVIEW: https://review.gluster.org/17425 (glusterd: Eliminate race in brick compatibility checking stage) posted (#1) for review on release-3.10 by Samikshan Bairagya (samikshan) COMMIT: https://review.gluster.org/17425 committed in release-3.10 by Raghavendra Talur (rtalur) ------ commit e91bfdec983ce41a395fe0b89d2a31fb5a6564a3 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: 1453087 Signed-off-by: Samikshan Bairagya <samikshan> Reviewed-on: https://review.gluster.org/17425 NetBSD-regression: NetBSD Build System <jenkins.org> Tested-by: Raghavendra Talur <rtalur> CentOS-regression: Gluster Build System <jenkins.org> Smoke: Gluster Build System <jenkins.org> Reviewed-by: Raghavendra Talur <rtalur> 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.10.3, please open a new bug report. glusterfs-3.10.3 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-June/031399.html [2] https://www.gluster.org/pipermail/gluster-users/ |