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

2015-03-09 Thread Emmanuel Dreyfus
On Fri, Mar 06, 2015 at 05:55:34PM +0530, Ravishankar N wrote: After bringing brick0 up, and performing ls abc/def, does afr_do_readdir() get called for def? If it does, then AFR will send lookup to both bricks via afr_inode_refresh() I think I tracked down the real problem. I now

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

2015-03-06 Thread Emmanuel Dreyfus
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

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

2015-03-06 Thread Emmanuel Dreyfus
Hi I tracked down the spurious failures of read-subvol-entry.t on NetBSD. Here is what should happen: we have a volume with brick0 and brick1. We disable self-heal, kill brick0, create a file in a directory, restart brick0, and we list directory content to check we find the file. The tested

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

2015-03-06 Thread Emmanuel Dreyfus
Ravishankar N ravishan...@redhat.com wrote: 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?