Bug 1426512
Summary: | Application VM paused after add brick operation and VM didn't comeup after power cycle. | ||
---|---|---|---|
Product: | [Community] GlusterFS | Reporter: | Krutika Dhananjay <kdhananj> |
Component: | sharding | Assignee: | bugs <bugs> |
Status: | CLOSED EOL | QA Contact: | bugs <bugs> |
Severity: | high | Docs Contact: | |
Priority: | unspecified | ||
Version: | 3.9 | CC: | amukherj, bsrirama, bugs, csaba, kdhananj, ravishankar, rcyriac, rgowdapp, rhs-bugs, sabose, sasundar, storage-qa-internal |
Target Milestone: | --- | Keywords: | Triaged |
Target Release: | --- | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | If docs needed, set a value | |
Doc Text: | Story Points: | --- | |
Clone Of: | 1420623 | Environment: | |
Last Closed: | 2017-03-08 12:32:17 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: | |||
Bug Blocks: | 1387878 |
Description
Krutika Dhananjay
2017-02-24 05:42:18 UTC
REVIEW: https://review.gluster.org/16751 (features/shard: Put onus of choosing the inode to resolve on individual fops) posted (#1) for review on release-3.9 by Krutika Dhananjay (kdhananj) REVIEW: https://review.gluster.org/16752 (features/shard: Fix EIO error on add-brick) posted (#1) for review on release-3.9 by Krutika Dhananjay (kdhananj) COMMIT: https://review.gluster.org/16751 committed in release-3.9 by Pranith Kumar Karampuri (pkarampu) ------ commit a10bc7da360c95524cd79b30d364134f2368f348 Author: Krutika Dhananjay <kdhananj> Date: Wed Feb 22 14:43:46 2017 +0530 features/shard: Put onus of choosing the inode to resolve on individual fops Backport of: https://review.gluster.org/16709 ... as opposed to adding checks in "common" functions to choose the inode to resolve based local->fop, which is rather ugly and prone to errors. Change-Id: I84c5b26160150f2fd87e7f245190c500a4b36bd8 BUG: 1426512 Signed-off-by: Krutika Dhananjay <kdhananj> Reviewed-on: https://review.gluster.org/16751 Smoke: Gluster Build System <jenkins.org> NetBSD-regression: NetBSD Build System <jenkins.org> CentOS-regression: Gluster Build System <jenkins.org> Reviewed-by: Pranith Kumar Karampuri <pkarampu> REVIEW: https://review.gluster.org/16752 (features/shard: Fix EIO error on add-brick) posted (#2) for review on release-3.9 by Krutika Dhananjay (kdhananj) COMMIT: https://review.gluster.org/16752 committed in release-3.9 by Pranith Kumar Karampuri (pkarampu) ------ commit 860ead4e36e4bf54bc5ed88d5ae3aa44d40358c3 Author: Krutika Dhananjay <kdhananj> Date: Tue May 17 15:37:18 2016 +0530 features/shard: Fix EIO error on add-brick Backport of: https://review.gluster.org/14419 DHT seems to link inode during lookup even before initializing inode ctx with layout information, which comes after directory healing. Consider two parallel writes. As part of the first write, shard sends lookup on .shard which in its return path would cause DHT to link .shard inode. Now at this point, when a second write is wound, inode_find() of .shard succeeds and as a result of this, shard goes to create the participant shards by issuing MKNODs under .shard. Since the layout is yet to be initialized, mknod fails in dht call path with EIO, leading to VM pauses. The fix involves shard maintaining a flag to denote whether a fresh lookup on .shard completed one network trip. If it didn't, all inode_find()s in fop path will be followed by a lookup before proceeding with the next stage of the fop. Big thanks to Raghavendra G and Pranith Kumar K for the RCA and subsequent inputs and feedback on the patch. Change-Id: Id0d160157ad8f6bcd52801a2173c5869517d0a96 BUG: 1426512 Signed-off-by: Krutika Dhananjay <kdhananj> Reviewed-on: https://review.gluster.org/16752 NetBSD-regression: NetBSD Build System <jenkins.org> CentOS-regression: Gluster Build System <jenkins.org> Smoke: Gluster Build System <jenkins.org> Reviewed-by: Pranith Kumar Karampuri <pkarampu> This bug is getting closed because GlusterFS-3.9 has reached its end-of-life [1]. Note: This bug is being closed using a script. No verification has been performed to check if it still exists on newer releases of GlusterFS. If this bug still exists in newer GlusterFS releases, please open a new bug against the newer release. [1]: https://www.gluster.org/community/release-schedule/ |