summaryrefslogtreecommitdiffstats
path: root/xlators/features/locks/src/common.c
diff options
context:
space:
mode:
authorkarthik-us <ksubrahm@redhat.com>2017-08-16 17:26:48 +0530
committerShyamsundar Ranganathan <srangana@redhat.com>2017-11-27 18:13:32 +0000
commit2475bfb4d25b20c20bc806771857a2de443835a2 (patch)
treec8d3fe9d34e845372aa136c2c72b5a1c1e09d80e /xlators/features/locks/src/common.c
parentae88dc134a89fa4af4ff2356abbf32f6f220dd53 (diff)
cluster/afr: Fix for arbiter becoming source
Problem: When eager-lock is on, and two writes happen in parallel on a FD we were observing the following behaviour: - First write fails on one data brick - Since the post-op is not yet happened, the inode refresh will get both the data bricks as readable and set it in the inode context - In flight split brain check see both the data bricks as readable and allows the second write - Second write fails on the other data brick - Now the post-op happens and marks both the data bricks as bad and arbiter will become source for healing Fix: Adding one more variable called write_suvol in inode context and it will have the in memory representation of the writable subvols. Inode refresh will not update this value and its lifetime is pre-op through unlock in the afr transaction. Initially the pre-op will set this value same as read_subvol in inode context and then in the in flight split brain check we will use this value instead of read_subvol. After all the checks we will update the value of this and set the read_subvol same as this to avoid having incorrect value in that. Change-Id: I2ef6904524ab91af861d59690974bbc529ab1af3 BUG: 1516313 Signed-off-by: karthik-us <ksubrahm@redhat.com> (cherry picked from commit 19f9bcff4aada589d4321356c2670ed283f02c03)
Diffstat (limited to 'xlators/features/locks/src/common.c')
0 files changed, 0 insertions, 0 deletions