<div dir="ltr">the very first thing you should check is if you have this setting set : <div><br></div><div>mmlsconfig envVar<br></div><div>
<p class="inbox-inbox-p1">envVar MLX4_POST_SEND_PREFER_BF 0 MLX4_USE_MUTEX 1 MLX5_SHUT_UP_BF 1 MLX5_USE_MUTEX 1</p>
<p class="inbox-inbox-p1">if that doesn't come back the way above you need to set it : </p><p class="inbox-inbox-p1">mmchconfig envVar="MLX4_POST_SEND_PREFER_BF=0 MLX5_SHUT_UP_BF=1 MLX5_USE_MUTEX=1 MLX4_USE_MUTEX=1"</p><p class="inbox-inbox-p1">there was a problem in the Mellanox FW in various versions that was never completely addressed (bugs where found and fixed, but it was never fully proven to be addressed) the above environment variables turn code on in the mellanox driver that prevents this potential code path from being used to begin with.</p><p class="inbox-inbox-p1">in Spectrum Scale 4.2.4 (not yet released) we added a workaround in Scale that even you don't set this variables the problem can't happen anymore until then the only choice you have is the envVar above (which btw ships as default on all ESS systems). </p><p class="inbox-inbox-p1">you also should be on the latest available Mellanox FW & Drivers as not all versions even have the code that is activated by the environment variables above, i think at a minimum you need to be at 3.4 but i don't remember the exact version. There had been multiple defects opened around this area, the last one i remember was  :</p><p class="inbox-inbox-p1">





</p><p class="inbox-inbox-p1">00154843 : ESS ConnectX-3 performance issue - spinning on pthread_spin_lock<br></p><p class="inbox-inbox-p1">you may ask your mellanox representative if they can get you access to this defect. while it was found on ESS , means on PPC64 and with ConnectX-3 cards its a general issue that affects all cards and on intel as well as Power. </p><br><div class="gmail_quote"><div dir="ltr">On Wed, Aug 2, 2017 at 8:58 AM Stijn De Weirdt <<a href="mailto:stijn.deweirdt@ugent.be">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 all,<br>
<br>
is there any documentation wrt data integrity in spectrum scale:<br>
assuming a crappy network, does gpfs garantee somehow that data written<br>
by client ends up safe in the nsd gpfs daemon; and similarly from the<br>
nsd gpfs daemon to disk.<br>
<br>
and wrt crappy network, what about rdma on crappy network? is it the same?<br>
<br>
(we are hunting down a crappy infiniband issue; ibm support says it's<br>
network issue; and we see no errors anywhere...)<br>
<br>
thanks a lot,<br>
<br>
stijn<br>
_______________________________________________<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/listinfo/gpfsug-discuss</a><br>
</blockquote></div></div></div>