[Bugs] [Bug 1516313] Bringing down data bricks in cyclic order results in arbiter brick becoming the source for heal.

bugzilla at redhat.com bugzilla at redhat.com
Thu Jan 18 18:20:31 UTC 2018


https://bugzilla.redhat.com/show_bug.cgi?id=1516313



--- Comment #6 from Worker Ant <bugzilla-bot at gluster.org> ---
COMMIT: https://review.gluster.org/19192 committed in release-3.13 by \"Karthik
U S\" <ksubrahm at redhat.com> with a commit message- cluster/afr: Fixing the
flaws in arbiter becoming source patch

Problem:
Setting the write_subvol value to read_subvol in case of metadata
transaction during pre-op (commit 19f9bcff4aada589d4321356c2670ed283f02c03)
might lead to the original problem of arbiter becoming source.

Scenario:
1) All bricks are up and good
2) 2 writes w1 and w2 are in progress in parallel
3) ctx->read_subvol is good for all the subvolumes
4) w1 succeeds on brick0 and fails on brick1, yet to do post-op on
   the disk
5) read/lookup comes on the same file and refreshes read_subvols back
   to all good
6) metadata transaction happens which makes ctx->write_subvol to be
   assigned with ctx->read_subvol which is all good
7) w2 succeeds on brick1 and fails on brick0 and this will update the
   brick in reverse order leading to arbiter becoming source

Fix:
Instead of setting the ctx->write_subvol to ctx->read_subvol in the
pre-op statge, if there is a metadata transaction, check in the
function __afr_set_in_flight_sb_status() if it is a data/metadata
transaction. Use the value of ctx->write_subvol if it is a data
transactions and ctx->read_subvol value for other transactions.

With this patch we assign the value of ctx->write_subvol in the
afr_transaction_perform_fop() with the on disk value, instead of
assigning it in the afr_changelog_pre_op() with the in memory value.

Change-Id: Id2025a7e965f0578af35b1abaac793b019c43cc4
BUG: 1516313
Signed-off-by: karthik-us <ksubrahm at redhat.com>
(cherry picked from commit ba149bac92d169ae2256dbc75202dc9e5d06538e)

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=ub0vbs116n&a=cc_unsubscribe


More information about the Bugs mailing list