<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
  <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
  <META NAME="GENERATOR" CONTENT="GtkHTML/3.26.3">
</HEAD>
<BODY>
Hello Lars and All,<BR>
<BR>
Please look bellow<BR>
<BR>
On Thu, 2009-10-29 at 16:53 +0100, Lars Ellenberg wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
On Thu, Oct 29, 2009 at 04:40:01PM +0200, Theophanis Kontogiannis wrote:
&gt; Hello all again.
&gt; 
&gt; In continuation to the bellow described issue, with integrity check
&gt; enabled, I used to get a crash at least once per 24 hours.

No.
You don't get &quot;crashes&quot;.

You configured it to fence its peer on connection loss,
and that is what it does.

</PRE>
</BLOCKQUOTE>
Correct in strict terminology. I just had in my mind that both nodes get fenced so I get &quot;crush&quot; in the sense of having no service.<BR>
But yes, the actual thing is that it gets fenced.<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE>
&gt; Now I have integrity check disabled and the cluster is running without
&gt; crashes for the last 9 days.
&gt; 
&gt; Could someone kindly provide some hints for the possible reasons  of
&gt; this observed behavior?
&gt; 
&gt; Off-loading is disabled on both dedicated gigabit NICs.

Either something modifies in-flight buffers,
which may or may not be intentional,
and may or may not be &quot;safe&quot; wrt file system data integrity.

Or you actually _do_ have data corruption.

If drbd detects checksum mismatch (== data corruption,
or more general: data received is not the same as
it was when calculating the checksum before it was
send), rather than knowingly writing diverging data,
drbd disconnects, and tries to reconnect,
hoping for the bitmap based resync to send
&quot;better&quot; data this time.

On disconnect, if so configured, a primary will call its
fence-peer handler.

You configured &quot;obliterate&quot; as fence peer handler.

So it &quot;obliterates&quot; its peer.

&gt; Also is integrity-check really needed (I have read the
&gt; documentation :) ) if it keeps on breaking the cluster?

If you rather have silent data corruption :-)

==&gt; Find the cause of the checksum mismatch.

</PRE>
</BLOCKQUOTE>
Is there any way to track to really low level the crc error? Turn on insane debugging on drbd or something else?<BR>
I can not think of any good way to go low level for that!<BR>
<BR>
Thank you All for your time.<BR>
T.K.<BR>
<BR>
</BODY>
</HTML>