[Gluster-devel] regression failures on afr/split-brain-resolution

[Ravishankar N]

On 07/24/2018 06:30 PM, Ravishankar N wrote:
>
>
>
> On 07/24/2018 02:56 PM, Raghavendra Gowdappa wrote:
>> All,
>>
>> I was trying to debug regression failures on [1] 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) ?
-Ravi
> -Ravi
>
>> Thoughts?
>>
>> [1] https://review.gluster.org/#/c/20549/
>>
>>
>> _______________________________________________
>> Gluster-devel mailing list
>> Gluster-devel at gluster.org
>> https://lists.gluster.org/mailman/listinfo/gluster-devel
>
>
>
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at gluster.org
> https://lists.gluster.org/mailman/listinfo/gluster-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/gluster-devel/attachments/20180724/169cb092/attachment.html>