[Gluster-devel] regression failures on afr/split-brain-resolution
ravishankar at redhat.com
Tue Jul 24 13:24:55 UTC 2018
On 07/24/2018 06:30 PM, Ravishankar N wrote:
> On 07/24/2018 02:56 PM, Raghavendra Gowdappa wrote:
>> I was trying to debug regression failures on  and observed that
>> split-brain-resolution.t was failing consistently.
>> TEST 45 (line 88): 0 get_pending_heal_count patchy
>> ./tests/basic/afr/split-brain-resolution.t .. 45/45 RESULT 45: 1
>> ./tests/basic/afr/split-brain-resolution.t .. Failed 17/45 subtests
>> Test Summary Report
>> ./tests/basic/afr/split-brain-resolution.t (Wstat: 0 Tests: 45
>> Failed: 17)
>> Failed tests: 24-26, 28-36, 41-45
>> On probing deeper, I observed a curious fact - on most of the
>> failures stat was not served from md-cache, but instead was wound
>> down to afr which failed stat with EIO as the file was in split
>> brain. So, I did another test:
>> * disabled md-cache
>> * mount glusterfs with attribute-timeout 0 and entry-timeout 0
>> Now the test fails always. So, I think the test relied on stat
>> requests being absorbed either by kernel attribute cache or md-cache.
>> When its not happening stats are reaching afr and resulting in
>> failures of cmds like getfattr etc.
> This indeed seems to be the case. Is there any way we can avoid the
> stat? When a getfattr is performed on the mount, aren't lookup +
> getfattr are the only fops that need to be hit in gluster?
Or should afr allow (f)stat even for replica-2 split-brains because it
is allowing lookup anyway (lookup cbk contains stat information from one
of its children) ?
>>  https://review.gluster.org/#/c/20549/
>> Gluster-devel mailing list
>> Gluster-devel at gluster.org
> Gluster-devel mailing list
> Gluster-devel at gluster.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Gluster-devel