path: root/tests/bugs/replicate/bug-977797.t
diff options
authorkarthik-us <>2017-08-16 17:26:48 +0530
committerRavishankar N <>2017-11-18 00:38:20 +0000
commit19f9bcff4aada589d4321356c2670ed283f02c03 (patch)
tree60917d166c9fc4ae9813601ebb062411f51f4e4b /tests/bugs/replicate/bug-977797.t
parentd71b53d2487ef93fc8a362ecc9fb735222e713e4 (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: 1482064 Signed-off-by: karthik-us <>
Diffstat (limited to 'tests/bugs/replicate/bug-977797.t')
0 files changed, 0 insertions, 0 deletions