<div class="gmail_quote">On Wed, May 4, 2011 at 7:29 PM, Joe Landman <span dir="ltr"><<a href="mailto:landman@scalableinformatics.com">landman@scalableinformatics.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On 05/04/2011 08:24 AM, Martin Schenker wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi all!<br>
<br>
Is there anybody who can give some pointers regarding which file to choose<br>
in a "split brain" condition?<br>
<br>
What tests do I need to run?<br>
</blockquote>
<br></div>
MD5sums. Did the logs indicate a split brain? Or are the signatures simply different?<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
What does the hex AFR code actually show? Is there a way to pinpoint the<br>
"better/worse" file for deletion?<br>
<br>
On pserver12:<br>
<br>
# file: mnt/gluster/brick0/storage/pserver3-19<br>
trusted.afr.storage0-client-5=0x3f0000010000000000000000<br>
<br>
On pserver13:<br>
<br>
# file: mnt/gluster/brick0/storage/pserver3-19<br>
trusted.afr.storage0-client-4=0xd70000010000000000000000<br>
<br>
These are test files, but I'd like to know what to do in a LIFE situation<br>
which will be just around the corner.<br>
<br>
The Timestamps show the same values, so I'm a bit puzzled HOW to choose a<br>
file.<br>
</blockquote>
<br></div>
File sizes and time stamps the same?<br>
<br>
Hmmm ... this sounds like an underlying caching issue (probably not flushed completely/properly on one or more of the units before reboot) with the base machine. Check the battery backup on the RAID and make sure it is functional.<br>
<br>
Also, run an file system check on the underlying backend storage.<br>
<br>
-- <br>
Joseph Landman, Ph.D<br>
Founder and CEO<br>
Scalable Informatics, Inc.<br>
email: <a href="mailto:landman@scalableinformatics.com" target="_blank">landman@scalableinformatics.com</a><br>
web : <a href="http://scalableinformatics.com" target="_blank">http://scalableinformatics.com</a><br>
<a href="http://scalableinformatics.com/sicluster" target="_blank">http://scalableinformatics.com/sicluster</a><br>
phone: +1 734 786 8423 x121<br>
fax : +1 866 888 3112<br>
cell : +1 734 612 4615<div><div></div><div class="h5"><br>
_______________________________________________<br>
Gluster-users mailing list<br>
<a href="mailto:Gluster-users@gluster.org" target="_blank">Gluster-users@gluster.org</a><br>
<a href="http://gluster.org/cgi-bin/mailman/listinfo/gluster-users" target="_blank">http://gluster.org/cgi-bin/mailman/listinfo/gluster-users</a><br>
</div></div></blockquote></div><br><br><div>Yes I agree with Joe. I will check the underlying disk filesystem first as first step. Look at kernel logs and dmesg for file system errors. Even if you did not find any, try running a forceful fsck on them. Another possible cause is silent data corruption. If everything is fine, then it can likely be a GlusterFS bug <br clear="all">
<br>-- <br>Anand Babu Periasamy<br>Blog [<a href="http://www.unlocksmith.org/" target="_blank">http://www.unlocksmith.org</a>]<br><br>Imagination is more important than knowledge --Albert Einstein<br>
</div>