diff options
author | Pranith Kumar K <pkarampu@redhat.com> | 2015-11-10 09:06:54 +0530 |
---|---|---|
committer | Xavier Hernandez <xhernandez@datalab.es> | 2015-11-11 05:48:02 -0800 |
commit | 9a69ad2c8438b9fbdcb133404a5d205f809bbb5a (patch) | |
tree | 63cea0a2eb5df48133b7f16681b65aee16af2a83 /libglusterfs | |
parent | d025d954a5c593ccb0838788e165c36cb3537b25 (diff) |
cluster/ec: fix bug in update_good
Problem:
Bricks that didn't participate in the fops are considered to be good. This is happening two fold.
Examples:
Case-1:
1) 2+1 volume. 'd1' directory on Brick-0 is bad.
2) readdir takes locks and lock->good_mask is '7'
3) readdir does xattrop and fop->mask is '6'.
4) because fop->expected is '1' lock->good_mask remains '7'
Case-2:
1) when all the bricks are up, it does lock + xattrop before op and figures out
all the bricks are good.
2) By the time second operation starts brick-0 is down. Now lock->good_mask
will always have the '0' bit set as long as the operations are happening on it.
because: "lock->good_mask &= ~fop->mask | fop->remaining" fop->mask doesn't
have '0' th bit.
3) When it comes time to perform the final xattrop in update_size_version
brick-0 comes online because of which it gives the same version to brick-0
as well thinking it has participated in all the transactions till then, even
when it didn't participate in the transactions.
Fix:
Case-1's fix: Update lock->good_mask in ec_prepare_update_cbk with latest
good/bad bricks
Case-2's fix: Consider non-participating brick as bad.
Change-Id: Ic01a733f8180131ded6a3cc784fcb1960758cf23
BUG: 1276989
Signed-off-by: Pranith Kumar K <pkarampu@redhat.com>
Reviewed-on: http://review.gluster.org/12561
Tested-by: NetBSD Build System <jenkins@build.gluster.org>
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Xavier Hernandez <xhernandez@datalab.es>
Diffstat (limited to 'libglusterfs')
0 files changed, 0 insertions, 0 deletions