[Gluster-devel] NetBSD's read-subvol-entry.t spurious failures explained

Ravishankar N ravishankar at redhat.com
Sat Mar 7 04:34:06 UTC 2015


On 03/06/2015 10:28 PM, Emmanuel Dreyfus wrote:
> On Fri, Mar 06, 2015 at 05:55:34PM +0530, Ravishankar N wrote:
>>> On NetBSD I can see that AFR never gets trusted.afr.patchy-client-0
>>> and walways things brick0 is fine. AFR randomly picks brick0 or brick1
>>> to list directory content, and when it picks brick0 the test fails.
>> After bringing brick0 up, and performing "ls abc/def", does afr_do_readdir()
>> get called for "def"?
> Yes, it is.
>
>> If it does,  then AFR will send lookup to both bricks via
>> afr_inode_refresh() ,
> How is it supposed to happen? I can see I do not get into
> afr_inode_refresh_do() after visiting afr_do_readdir().
>

If only the brick process is killed and brought back: afr_do_readdir() 
-->afr_read_txn() -->afr_inode_refresh() because 
"local->event_generation != event_generation".

But since in the test case, we are doing a 'volume start force' , this 
code path doesn't seem to be hit and looks like we are calling 
local->readfn() from afr_read_txn(). But read_subvol still is 1 (i.e the 
2nd brick).  Is that the case for you too? i.e does afr_readdir_wind() 
get called for subvol=1?






More information about the Gluster-devel mailing list