https://jira.whamcloud.com This file is an XML representation of an issue en-us 9.4.14 940014 05-12-2023 https://jira.whamcloud.com/browse/LU-1419 Lustre <p>Cray is preparing to submit gnilnd for upstream adoption. This ticket is for tracking that work.</p> LU-1419

Tracking ticket for gnilnd push

New Feature Minor Resolved Fixed WC Triage Chris Horn lnet Thu, 17 May 2012 12:12:51 +0000 Wed, 19 Dec 2012 19:42:51 +0000 Wed, 19 Dec 2012 19:42:51 +0000 Lustre 2.4.0 0 6 <p>Will this work only be aimed at the master branch? Also during ORNL testing of IR recovery we discovered some old left over code from the catamount days that impacted the recovery time. Should we merge that fix under this ticket? Its just the INITIAL_CONNECT_TIMEOUT in obd_support.h.</p> <p>Yes, we'll aim at master. Then, if there is reason to push back, we can do so later.</p> <p>Other changes that aren't related to the gnilnd should be tracked in a different ticket. James, can you open one for the INITIAL_CONNECT_TIMEOUT problem?</p> <p>The ticket is in <a href="http://jira.whamcloud.com/browse/LU-1422" class="external-link" rel="nofollow">http://jira.whamcloud.com/browse/LU-1422</a> for this. Want to let you know for peer review. Thanks</p> <p>Our push of gnilnd is eminent. However, it was written before we adopted the retab policy. Can we please submit with the old whitespace style? It would help us from touching every single line or keeping our version and the contributed version different. Thoughts or suggestions?</p> <p>Here is a handy script I used for re-tabbing.After you commit your code just run it and then push it upstream.<br/> .<br/> #!/bin/bash -e<br/> #</p> <ol> <li>Rewrite the last commit to remove any trailing whitespace</li> <li>in the new version of changed lines.</li> <li>Then replace space-based indentation with TAB based indentation</li> <li>based on TABS at every eight position<br/> #<br/> [[ -z $TRACE ]] || set -x<br/> trap "rm -f $tmpf" 0<br/> tmpf1=$TMP/$$.1.diff<br/> tmpf2=$TMP/$$.2.diff<br/> git show --binary &gt;$tmpf1<br/> perl -p -e 's/^{(&#43;.<b>?)[ \t]+$/$1/; while(m/}(&#43;\t</b>)( {1,7} <p>\t| </p> {8} <p>)(.*)/) </p> { $_=$1."\t".$3."\n"; } <p>' &lt;$tmpf1 &gt;$tmpf2<br/> if ! cmp -s $tmpf1 $tmpf2<br/> then<br/> git apply --binary --index -R --whitespace=nowarn $tmpf1<br/> git apply --binary --index $tmpf2<br/> GIT_EDITOR=true git commit --amend<br/> else<br/> echo "No changes"<br/> fi</p></li> </ol> <p>Attached to ticket since JIRA managed my script.</p> <p><a href="http://review.whamcloud.com/#change,3381" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/#change,3381</a></p> <p>Question: What will be Cray's policy for keeping the gnilnd code synchronized between the Lustre main repository and the Cray repository? Will you be doing code drops to match shipping versions? How will changes made by non-Cray community members be handled?</p> <p>Doug, good question. I don't know exactly, it likely won't be an instantaneous sync. However, Cray won't make code drops to match shipping versions. We intend to keep to the 'master' model. (The version submitted here is already "ahead" of our released versions). Cray will push up changes on as a regular basis as we can manage. Surely, it would be nice to stay current with 'master'. For other contributions, I suggest that we handle those as any other: through Gerrit with community review.</p> <p>Hi Cory.</p> <p> I have been regularly testing master on our Gemini test bed so I have a motivation to keep this driver working <img class="emoticon" src="https://jira.whamcloud.com/images/icons/emoticons/smile.png" height="16" width="16" align="absmiddle" alt="" border="0"/> If Cray doesn't mind I have no issue with keeping this driver in sync. Please look it over. The error code you can inject have changed and I just guessed what the values are so if you attempt to regression test internally this latest patch your test will most likely fail. So we need to sync up on that. Also from your earlier patch some of the Whamcloud engineers had concerns about the certain parts of the code. I didn't want to change those parts of the code without a serious inspection from the cray engineer working on this LNET driver as well. Any changes will be welcomed for testing.</p> <p>I have pushed a updated driver with Isaac suggestions. The driver appears to work pretty well. The only thing I have observed with the driver is that on server node after LNET is brought up it can't ping the MGS until after I first ping the routers. Issac have any idea what could be causing that?</p> <p>Can you reproduce it?</p> <p>Found the bug in the driver causing this. The latest patch works now.</p> <p>Patch landed for 2.4. I suggest that any subsequent updates are handled under separate tickets for clarity.</p> Development Rank 1|hzvqaf: Rank (Obsolete) 8135