<div dir="ltr">On Sun, Sep 29, 2013 at 11:27 PM, Amar Tumballi <span dir="ltr"><<a href="mailto:atumball@redhat.com" target="_blank">atumball@redhat.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 09/30/2013 09:25 AM, Emmanuel Dreyfus wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi<br>
<br>
I tested 3.4.1 on a long run ang got a spurious split brain with all-null<br>
pending matrix again:<br>
<br>
[2013-09-30 00:25:12.962127] E<br>
[afr-self-heal-common.c:197:<u></u>afr_sh_print_split_brain_log]<br>
0-gfs341-replicate-1: Unable to self-heal contents of<br>
'/manu/netbsd/usr/src/lib/<u></u>libpuffs/obj/dispatcher.pico' (possible<br>
split-brain). Please delete the file from all but the preferred subvolume.-<br>
Pending matrix: [ [ 0 0 ] [ 0 0 ] ]<br>
<br>
The bug is described with log files here:<br>
<a href="https://bugzilla.redhat.com/show_bug.cgi?id=1005526" target="_blank">https://bugzilla.redhat.com/<u></u>show_bug.cgi?id=1005526</a><br>
<br>
We previously thought that it was caused by heterogeneous setup (i386 +<br>
amd64), but it is not the case in my latest test. The only known workaround so<br>
far is to disable eager locks.<br>
<br>
The split brain is real, as shown below. What I do not really understand is<br>
why I have 4 copies of the file, as this is a 2x2 stripped-replicated volume.<br>
The first set of replicas are fine, the second set has two file filled with<br>
zeros, one wih correct size, the other being truncated.<br>
<br>
silo:/export/wd2a/manu/netbsd/<u></u>usr/src/lib/libpuffs/obj/<u></u>dispatcher.pico<br>
-rw-r--r-- 2 manu manu 11916 Sep 30 02:23 dispatcher.pico<br>
SHA1(dispatcher.pico) = b512c2924194ab9d001aec402ef037<u></u>225f9a6e6d<br>
<br>
hangar:/export/wd1a/manu/<u></u>netbsd/usr/src/lib/libpuffs/<u></u>obj/dispatcher.pico<br>
-rw-r--r-- 2 manu manu 11916 Sep 30 02:23 dispatcher.pico<br>
SHA1(dispatcher.pico) = b512c2924194ab9d001aec402ef037<u></u>225f9a6e6d<br>
<br>
hangar:/export/wd3a/manu/<u></u>netbsd/usr/src/lib/libpuffs/<u></u>obj/dispatcher.pico<br>
-rw-r--r-- 2 manu manu 11916 Sep 30 02:23 dispatcher.pico<br>
SHA1(dispatcher.pico) = 3bdf1048eff02260594f7385449dcc<u></u>37bd09b78f<br>
NB: filled with zeroes<br>
<br>
debacle:/export/wd1a/manu/<u></u>netbsd/usr/src/lib/libpuffs/<u></u>obj/dispatcher.pico<br>
-rw-r--r-- 2 manu manu 11049 Sep 30 02:23 dispatcher.pico<br>
SHA1(dispatcher.pico) = 5357efe9fa5299b59a279b32ce8047<u></u>67c6ffc116<br>
NB: filled with zeroes<br>
<br>
Is it possible to have the same file on different stripes in other situations<br>
than during a rename operation?<br>
</blockquote>
<br></div></div>
I guess the solution to these issues is in the works : <a href="http://review.gluster.org/6010" target="_blank">http://review.gluster.org/6010</a><br>
<br>
Would advise to run the first qa bits from 3.5.0 branch :-)<br></blockquote><div><br></div><div>This seems to be a striped-replicated configuration. I'm not sure what the exact issue is. It may not be NetBSD specific either, because we have note tested striped-replicated configuration in the way described by Emmanuel.</div>
<div><br></div><div>Avati</div></div></div></div>