Bug 1688115 - Data heal not checking for locks on source & sink(s) before healing
Summary: Data heal not checking for locks on source & sink(s) before healing
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: GlusterFS
Classification: Community
Component: replicate
Version: mainline
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Karthik U S
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-03-13 07:29 UTC by Karthik U S
Modified: 2020-02-13 09:39 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-02-13 09:39:23 UTC
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Gluster.org Gerrit 22349 0 None Merged cluster/afr: Check for lock on source & sink before doing data heal 2020-02-13 09:39:22 UTC

Description Karthik U S 2019-03-13 07:29:20 UTC
Description of problem:

During data heal, we try to take locks on all the bricks, but we do not check for whether we got the lock on at least the source and one of the sink bricks before starting the heal.
In function afr_selfheal_data_block(), we only check for the lock count to be equal to or greater than the number of sinks. There can be a case where we have 2 source bricks and one sink and the locking is successful on only the source brick(s). In this case we continue with the healing on sink without having a lock, which is not correct.

Comment 1 Worker Ant 2019-03-13 07:37:33 UTC
REVIEW: https://review.gluster.org/22349 (cluster/afr: Check for lock on source & sink before doing data heal) posted (#1) for review on master by Karthik U S

Comment 2 Worker Ant 2020-02-13 09:39:23 UTC
REVIEW: https://review.gluster.org/22349 (cluster/afr: Check for lock on source & sink before doing data heal) merged (#2) on master by Pranith Kumar Karampuri


Note You need to log in before you can comment on or make changes to this bug.