Dear Patric,<br><br>That seemed to make the trick because we can now see the file and access it.<br><br>Is there any place where it could be documented?<br><br>Thanks a lot,<br>Samuel<br><br><div class="gmail_quote">On 8 March 2013 10:40, Patric Uebele <span dir="ltr"><<a href="mailto:puebele@redhat.com" target="_blank">puebele@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Samuel,<br>
<br>
can you try to drop caches on the clients:<br>
<br>
“echo 3 > /proc/sys/vm/drop_caches”<br>
<br>
/Patric<br>
<div><div class="h5"><br>
On Fri, 2013-03-08 at 10:13 +0100, samuel wrote:<br>
> No one around can help with this situation?<br>
><br>
> The file finally got "corrupted" and it's impossible to read from any<br>
> of the current mounted native gluster clients.<br>
><br>
> Reading the attributes, all flags are set as 0:<br>
><br>
> # file: dd29900f215b175939816f94c907a31b<br>
> trusted.afr.storage-client-6=0x000000000000000000000000<br>
> trusted.afr.storage-client-7=0x000000000000000000000000<br>
> trusted.gfid=0x59311906edf04464be5f00f505b3aebb<br>
> trusted.storage-stripe-1.stripe-count=0x3200<br>
> trusted.storage-stripe-1.stripe-index=0x3100<br>
> trusted.storage-stripe-1.stripe-size=0x31333130373200<br>
><br>
> so there should not be read as split brain from clients but we got the<br>
> following logs:<br>
> "split brain detected during lookup of"<br>
><br>
> thanks in advance,<br>
> Samuel.<br>
><br>
><br>
> On 4 March 2013 14:37, samuel <<a href="mailto:samu60@gmail.com">samu60@gmail.com</a>> wrote:<br>
> Hi folks,<br>
><br>
> We have detected a split-brain on 3.3.0 stripped replicated 8<br>
> nodes cluster.<br>
> We've followed the instructions from:<br>
> <a href="http://www.gluster.org/2012/07/fixing-split-brain-with-glusterfs-3-3/" target="_blank">http://www.gluster.org/2012/07/fixing-split-brain-with-glusterfs-3-3/</a><br>
> and we've manually recovered the information.<br>
><br>
> The problem is that we've got 4 gluster native clients and<br>
> from 2 of them we got<br>
> 0-storage-replicate-3: failed to open as split brain seen,<br>
> returning EIO<br>
> but from 2 of them we can access the recovered file.<br>
><br>
> We're this information locally storage on clients so we can<br>
> "update" all of them and recover the information in a<br>
> "coherent" manner?<br>
><br>
> Thanks a lot in advance,<br>
> Samuel.<br>
><br>
</div></div>> _______________________________________________<br>
> Gluster-users mailing list<br>
> <a href="mailto:Gluster-users@gluster.org">Gluster-users@gluster.org</a><br>
> <a href="http://supercolony.gluster.org/mailman/listinfo/gluster-users" target="_blank">http://supercolony.gluster.org/mailman/listinfo/gluster-users</a><br>
<br>
--<br>
Patric Uebele<br>
Solution Architect Storage<br>
<br>
Red Hat GmbH<br>
Technopark II, Haus C<br>
Werner-von-Siemens-Ring 14<br>
85630 Grasbrunn<br>
Germany<br>
<br>
Office: <a href="tel:%2B49%2089%20205071-162" value="+4989205071162">+49 89 205071-162</a><br>
Cell: <a href="tel:%2B49%20172%20669%2014%2099" value="+491726691499">+49 172 669 14 99</a><br>
mailto: <a href="mailto:Patric.Uebele@redhat.com">Patric.Uebele@redhat.com</a><br>
<br>
gpg keyid: 48E64CC1<br>
gpg fingerprint: C63E 6320 A03B 4410 D208 4EE7 12FC D0E6 48E6 4CC1<br>
<br>
____________________________________________________________________<br>
Reg. Adresse: Red Hat GmbH, Werner-von-Siemens-Ring 14, 85630 Grasbrunn<br>
Handelsregister: Amtsgericht Muenchen HRB 153243<br>
Geschaeftsfuehrer: Mark Hegarty, Charlie Peters, Michael Cunningham,<br>
Charles Cachera<br>
</blockquote></div><br>