<div dir="ltr">i actually hit this assert and turned it in to support on this version:<br>Build branch "4.2.2.3 efix6 (987197)".<br><br>i was told do to exactly what sven mentioned.<br><br>i thought it strange that i did NOT hit the assert in a no pass but hit it in a yes pass.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 3, 2017 at 9:06 AM, Sven Oehme <span dir="ltr"><<a href="mailto:oehmes@gmail.com" target="_blank">oehmes@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">a trace during a mmfsck with the checksum parameters turned on would reveal it. <div>the support team should be able to give you specific triggers to cut a trace during checksum errors , this way the trace is cut when the issue happens and then from the trace on server and client side one can extract which card was used on each side. </div><span class="HOEnZb"><font color="#888888"><div><br></div><div>sven</div></font></span></div><div class="HOEnZb"><div class="h5"><br><div class="gmail_quote"><div dir="ltr">On Wed, Aug 2, 2017 at 2:53 PM Stijn De Weirdt <<a href="mailto:stijn.deweirdt@ugent.be" target="_blank">stijn.deweirdt@ugent.be</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">hi steve,<br>
<br>
> The nsdChksum settings for none GNR/ESS based system is not officially<br>
> supported.    It will perform checksum on data transfer over the network<br>
> only and can be used to help debug data corruption when network is a<br>
> suspect.<br>
i'll take not officially supported over silent bitrot any day.<br>
<br>
><br>
> Did any of those "Encountered XYZ checksum errors on network I/O to NSD<br>
> Client disk" warning messages resulted in disk been changed to "down"<br>
> state due to IO error?<br>
no.<br>
<br>
 If no disk IO error was reported in GPFS log,<br>
> that means data was retransmitted successfully on retry.<br>
we suspected as much. as sven already asked, mmfsck now reports clean<br>
filesystem.<br>
i have an ibdump of 2 involved nsds during the reported checksums, i'll<br>
have a closer look if i can spot these retries.<br>
<br>
><br>
> As sven said, only GNR/ESS provids the full end to end data integrity.<br>
so with the silent network error, we have high probabilty that the data<br>
is corrupted.<br>
<br>
we are now looking for a test to find out what adapters are affected. we<br>
hoped that nsdperf with verify=on would tell us, but it doesn't.<br>
<br>
><br>
> Steve Y. Xiao<br>
><br>
><br>
><br>
><br>
><br>
><br>
> ______________________________<wbr>_________________<br>
> gpfsug-discuss mailing list<br>
> gpfsug-discuss at <a href="http://spectrumscale.org" rel="noreferrer" target="_blank">spectrumscale.org</a><br>
> <a href="http://gpfsug.org/mailman/listinfo/gpfsug-discuss" rel="noreferrer" target="_blank">http://gpfsug.org/mailman/<wbr>listinfo/gpfsug-discuss</a><br>
><br>
______________________________<wbr>_________________<br>
gpfsug-discuss mailing list<br>
gpfsug-discuss at <a href="http://spectrumscale.org" rel="noreferrer" target="_blank">spectrumscale.org</a><br>
<a href="http://gpfsug.org/mailman/listinfo/gpfsug-discuss" rel="noreferrer" target="_blank">http://gpfsug.org/mailman/<wbr>listinfo/gpfsug-discuss</a><br>
</blockquote></div>
</div></div><br>______________________________<wbr>_________________<br>
gpfsug-discuss mailing list<br>
gpfsug-discuss at <a href="http://spectrumscale.org" rel="noreferrer" target="_blank">spectrumscale.org</a><br>
<a href="http://gpfsug.org/mailman/listinfo/gpfsug-discuss" rel="noreferrer" target="_blank">http://gpfsug.org/mailman/<wbr>listinfo/gpfsug-discuss</a><br>
<br></blockquote></div><br></div>