<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns:mv="http://macVmlSchemaUri" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Title" content="">
<meta name="Keywords" content="">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
{font-family:"Courier New";
panose-1:2 7 3 9 2 2 5 2 4 4;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:sans-serif;
panose-1:0 0 0 0 0 0 0 0 0 0;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
tt
{mso-style-priority:99;
font-family:"Courier New";}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:Calibri;
color:windowtext;}
span.msoIns
{mso-style-type:export-only;
mso-style-name:"";
text-decoration:underline;
color:teal;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style>
</head>
<body bgcolor="white" lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri">The tail isn’t the issue; that’ my addition, so that I didn’t have to paste the hundred or so line nodelist into the thread.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri">The actual command is<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri">tsctl shownodes up | $tr ',' '\n' | $sort -o $upnodefile<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri">But you can see in my tailed output that the last hostname listed is cut-off halfway through the hostname. Less obvious in the example, but true, is the fact that it’s only showing the
first 120 hosts, when we have 403 nodes in our gpfs cluster.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri">[root@sgate2 ~]# tsctl shownodes up | tr ',' '\n' | wc -l<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri">120<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri">[root@sgate2 ~]# mmlscluster | grep '\-opa' | wc -l<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri">403<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri">Perhaps more explicitly, it looks like `tsctl shownodes up` can only transmit 3983 characters.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri">[root@sgate2 ~]# tsctl shownodes up | wc -c<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri">3983<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri">Again, I’m convinced this is a bug not only because the command doesn’t actually produce a list of all of the up nodes in our cluster; but because the last name listed is incomplete.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri">[root@sgate2 ~]# tsctl shownodes up | tr ',' '\n' | tail -n 1<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri">shas0260-opa.rc.int.col[root@sgate2 ~]#<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri">I’d continue my investigation within tsctl itself but, alas, it’s a binary with no source code available to me. :)<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri">I’m trying to get this opened as a bug / PMR; but I’m still working through the DDN support infrastructure. Thanks for reporting it, though.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri">For the record:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri">[root@sgate2 ~]# rpm -qa | grep -i gpfs<o:p></o:p></span></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:Calibri">gpfs</span></b><span style="font-size:11.0pt;font-family:Calibri">.base-4.2.1-2.x86_64<o:p></o:p></span></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:Calibri">gpfs</span></b><span style="font-size:11.0pt;font-family:Calibri">.msg.en_US-4.2.1-2.noarch<o:p></o:p></span></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:Calibri">gpfs</span></b><span style="font-size:11.0pt;font-family:Calibri">.gplbin-3.10.0-327.el7.x86_64-4.2.1-0.x86_64<o:p></o:p></span></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:Calibri">gpfs</span></b><span style="font-size:11.0pt;font-family:Calibri">.gskit-8.0.50-57.x86_64<o:p></o:p></span></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:Calibri">gpfs</span></b><span style="font-size:11.0pt;font-family:Calibri">.gpl-4.2.1-2.noarch<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri">nfs-ganesha-<b>gpfs</b>-2.3.2-0.ibm24.el7.x86_64<o:p></o:p></span></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:Calibri">gpfs</span></b><span style="font-size:11.0pt;font-family:Calibri">.ext-4.2.1-2.x86_64<o:p></o:p></span></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:Calibri">gpfs</span></b><span style="font-size:11.0pt;font-family:Calibri">.gplbin-3.10.0-327.36.3.el7.x86_64-4.2.1-2.x86_64<o:p></o:p></span></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:Calibri">gpfs</span></b><span style="font-size:11.0pt;font-family:Calibri">.docs-4.2.1-2.noarch<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri">~jonathon<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri"><o:p> </o:p></span></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-family:Calibri;color:black">From: </span>
</b><span style="font-family:Calibri;color:black"><gpfsug-discuss-bounces@spectrumscale.org> on behalf of Olaf Weiser <olaf.weiser@de.ibm.com><br>
<b>Reply-To: </b>gpfsug main discussion list <gpfsug-discuss@spectrumscale.org><br>
<b>Date: </b>Tuesday, January 31, 2017 at 1:30 AM<br>
<b>To: </b>gpfsug main discussion list <gpfsug-discuss@spectrumscale.org><br>
<b>Subject: </b>Re: [gpfsug-discuss] CES doesn't assign addresses to nodes<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"sans-serif","serif"">Hi ...same thing here.. everything after 10 nodes will be truncated..
</span><br>
<span style="font-size:10.0pt;font-family:"sans-serif","serif"">though I don't have an issue with it ... I 'll open a PMR .. and I recommend you to do the same thing.. ;-)
</span><br>
<br>
<span style="font-size:10.0pt;font-family:"sans-serif","serif"">the reason seems simple.. it is the
<i>"| tail" .</i>at the end of the command.. .. which truncates the output to the last 10 items...
</span><br>
<br>
<span style="font-size:10.0pt;font-family:"sans-serif","serif"">should be easy to fix..
</span><br>
<span style="font-size:10.0pt;font-family:"sans-serif","serif"">cheers</span><br>
<span style="font-size:10.0pt;font-family:"sans-serif","serif"">olaf</span><br>
<br>
<br>
<br>
<br>
<br>
<span style="font-size:7.5pt;font-family:"sans-serif","serif";color:#5F5F5F">From: </span><span style="font-size:7.5pt;font-family:"sans-serif","serif"">Jonathon A Anderson <jonathon.anderson@colorado.edu></span><br>
<span style="font-size:7.5pt;font-family:"sans-serif","serif";color:#5F5F5F">To: </span><span style="font-size:7.5pt;font-family:"sans-serif","serif"">"gpfsug-discuss@spectrumscale.org" <gpfsug-discuss@spectrumscale.org></span><br>
<span style="font-size:7.5pt;font-family:"sans-serif","serif";color:#5F5F5F">Date: </span><span style="font-size:7.5pt;font-family:"sans-serif","serif"">01/30/2017 11:11 PM</span><br>
<span style="font-size:7.5pt;font-family:"sans-serif","serif";color:#5F5F5F">Subject: </span><span style="font-size:7.5pt;font-family:"sans-serif","serif"">Re: [gpfsug-discuss] CES doesn't assign addresses to nodes</span><br>
<span style="font-size:7.5pt;font-family:"sans-serif","serif";color:#5F5F5F">Sent by: </span><span style="font-size:7.5pt;font-family:"sans-serif","serif"">gpfsug-discuss-bounces@spectrumscale.org</span><o:p></o:p></p>
<div class="MsoNormal" align="center" style="text-align:center">
<hr size="2" width="100%" noshade="" style="color:#AAAAAA" align="center">
</div>
<p class="MsoNormal"><br>
<br>
<br>
<tt><span style="font-size:10.0pt">In trying to figure this out on my own, I’m relatively certain I’ve found a bug in GPFS related to the truncation of output from `tsctl shownodes up`. Any chance someone in development can confirm?</span></tt><span style="font-size:10.0pt;font-family:"Courier New""><br>
<br>
<br>
<tt>Here are the details of my investigation:</tt><br>
<br>
<br>
<tt>## GPFS is up on sgate2</tt><br>
<br>
<tt>[root@sgate2 ~]# mmgetstate</tt><br>
<br>
<tt>Node number Node name GPFS state </tt><br>
<tt>------------------------------------------</tt><br>
<tt> 414 sgate2-opa active</tt><br>
<br>
<br>
<tt>## but if I tell ces to explicitly put one of our ces addresses on that node, it says that GPFS is down</tt><br>
<br>
<tt>[root@sgate2 ~]# mmces address move --ces-ip 10.225.71.102 --ces-node sgate2-opa</tt><br>
<tt>mmces address move: GPFS is down on this node.</tt><br>
<tt>mmces address move: Command failed. Examine previous error messages to determine cause.</tt><br>
<br>
<br>
<tt>## the “GPFS is down on this node” message is defined as code 109 in mmglobfuncs</tt><br>
<br>
<tt>[root@sgate2 ~]# grep --before-context=1 "GPFS is down on this node." /usr/lpp/mmfs/bin/mmglobfuncs</tt><br>
<tt> 109 ) msgTxt=\</tt><br>
<tt>"%s: GPFS is down on this node."</tt><br>
<br>
<br>
<tt>## and is generated by printErrorMsg in mmcesnetmvaddress when it detects that the current node is identified as “down” by getDownCesNodeList</tt><br>
<br>
<tt>[root@sgate2 ~]# grep --before-context=5 'printErrorMsg 109' /usr/lpp/mmfs/bin/mmcesnetmvaddress</tt><br>
<tt> downNodeList=$(getDownCesNodeList)</tt><br>
<tt> for downNode in $downNodeList</tt><br>
<tt> do</tt><br>
<tt> if [[ $toNodeName == $downNode ]]</tt><br>
<tt> then</tt><br>
<tt> printErrorMsg 109 "$mmcmd"</tt><br>
<br>
<br>
<tt>## getDownCesNodeList is the intersection of all ces nodes with GPFS cluster nodes listed in `tsctl shownodes up`</tt><br>
<br>
<tt>[root@sgate2 ~]# grep --after-context=16 '^function getDownCesNodeList' /usr/lpp/mmfs/bin/mmcesfuncs</tt><br>
<tt>function getDownCesNodeList</tt><br>
<tt>{</tt><br>
<tt> typeset sourceFile="mmcesfuncs.sh"</tt><br>
<tt> [[ -n $DEBUG || -n $DEBUGgetDownCesNodeList ]] && set -x</tt><br>
<tt> $mmTRACE_ENTER "$*"</tt><br>
<br>
<tt> typeset upnodefile=${cmdTmpDir}upnodefile</tt><br>
<tt> typeset downNodeList</tt><br>
<br>
<tt> # get all CES nodes</tt><br>
<tt> $sort -o $nodefile $mmfsCesNodes.dae</tt><br>
<br>
<tt> $tsctl shownodes up | $tr ',' '\n' | $sort -o $upnodefile</tt><br>
<br>
<tt> downNodeList=$($comm -23 $nodefile $upnodefile)</tt><br>
<tt> print -- $downNodeList</tt><br>
<tt>} #----- end of function getDownCesNodeList --------------------</tt><br>
<br>
<br>
<tt>## but not only are the sgate nodes not listed by `tsctl shownodes up`; its output is obviously and erroneously truncated</tt><br>
<br>
<tt>[root@sgate2 ~]# tsctl shownodes up | tr ',' '\n' | tail</tt><br>
<tt>shas0251-opa.rc.int.colorado.edu</tt><br>
<tt>shas0252-opa.rc.int.colorado.edu</tt><br>
<tt>shas0253-opa.rc.int.colorado.edu</tt><br>
<tt>shas0254-opa.rc.int.colorado.edu</tt><br>
<tt>shas0255-opa.rc.int.colorado.edu</tt><br>
<tt>shas0256-opa.rc.int.colorado.edu</tt><br>
<tt>shas0257-opa.rc.int.colorado.edu</tt><br>
<tt>shas0258-opa.rc.int.colorado.edu</tt><br>
<tt>shas0259-opa.rc.int.colorado.edu</tt><br>
<tt>shas0260-opa.rc.int.col[root@sgate2 ~]#</tt><br>
<br>
<br>
<tt>## I expect that this is a bug in GPFS, likely related to a maximum output buffer for `tsctl shownodes up`.</tt><br>
<br>
<br>
<br>
<tt>On 1/24/17, 12:48 PM, "Jonathon A Anderson" <jonathon.anderson@colorado.edu> wrote:</tt><br>
<br>
<tt> I think I'm having the same issue described here:</tt><br>
<tt> </tt><br>
<tt> </tt></span><a href="http://www.spectrumscale.org/pipermail/gpfsug-discuss/2016-October/002288.html"><tt><span style="font-size:10.0pt">http://www.spectrumscale.org/pipermail/gpfsug-discuss/2016-October/002288.html</span></tt></a><span style="font-size:10.0pt;font-family:"Courier New""><br>
<tt> </tt><br>
<tt> Any advice or further troubleshooting steps would be much appreciated. Full disclosure: I also have a DDN case open. (78804)</tt><br>
<tt> </tt><br>
<tt> We've got a four-node (snsd{1..4}) DDN gridscaler system. I'm trying to add two CES protocol nodes (sgate{1,2}) to serve NFS.
</tt><br>
<tt> </tt><br>
<tt> Here's the steps I took: </tt><br>
<tt> </tt><br>
<tt> --- </tt><br>
<tt> mmcrnodeclass protocol -N sgate1-opa,sgate2-opa </tt><br>
<tt> mmcrnodeclass nfs -N sgate1-opa,sgate2-opa </tt><br>
<tt> mmchconfig cesSharedRoot=/gpfs/summit/ces </tt><br>
<tt> mmchcluster --ccr-enable </tt><br>
<tt> mmchnode --ces-enable -N protocol </tt><br>
<tt> mmces service enable NFS </tt><br>
<tt> mmces service start NFS -N nfs </tt><br>
<tt> mmces address add --ces-ip 10.225.71.104,10.225.71.105 </tt><br>
<tt> mmces address policy even-coverage </tt><br>
<tt> mmces address move --rebalance </tt><br>
<tt> --- </tt><br>
<tt> </tt><br>
<tt> This worked the very first time I ran it, but the CES addresses weren't re-distributed after restarting GPFS or a node reboot.
</tt><br>
<tt> </tt><br>
<tt> Things I've tried: </tt><br>
<tt> </tt><br>
<tt> * disabling ces on the sgate nodes and re-running the above procedure </tt>
<br>
<tt> * moving the cluster and filesystem managers to different snsd nodes </tt>
<br>
<tt> * deleting and re-creating the cesSharedRoot directory </tt><br>
<tt> </tt><br>
<tt> Meanwhile, the following log entry appears in mmfs.log.latest every ~30s: </tt>
<br>
<tt> </tt><br>
<tt> --- </tt><br>
<tt> Mon Jan 23 20:31:20 MST 2017: mmcesnetworkmonitor: Found unassigned address 10.225.71.104
</tt><br>
<tt> Mon Jan 23 20:31:20 MST 2017: mmcesnetworkmonitor: Found unassigned address 10.225.71.105
</tt><br>
<tt> Mon Jan 23 20:31:20 MST 2017: mmcesnetworkmonitor: handleNetworkProblem with lock held: assignIP 10.225.71.104_0-_+,10.225.71.105_0-_+ 1
</tt><br>
<tt> Mon Jan 23 20:31:20 MST 2017: mmcesnetworkmonitor: Assigning addresses: 10.225.71.104_0-_+,10.225.71.105_0-_+
</tt><br>
<tt> Mon Jan 23 20:31:20 MST 2017: mmcesnetworkmonitor: moveCesIPs: 10.225.71.104_0-_+,10.225.71.105_0-_+
</tt><br>
<tt> --- </tt><br>
<tt> </tt><br>
<tt> Also notable, whenever I add or remove addresses now, I see this in mmsysmonitor.log (among a lot of other entries):
</tt><br>
<tt> </tt><br>
<tt> --- </tt><br>
<tt> 2017-01-23T20:40:56.363 sgate1 D ET_cesnetwork Entity state without requireUnique: ces_network_ips_down WARNING No CES relevant NICs detected - Service.calculateAndUpdateState:275
</tt><br>
<tt> 2017-01-23T20:40:11.364 sgate1 D ET_cesnetwork Update multiple entities at once {'p2p2': 1, 'bond0': 1, 'p2p1': 1} - Service.setLocalState:333
</tt><br>
<tt> --- </tt><br>
<tt> </tt><br>
<tt> For the record, here's the interface I expect to get the address on sgate1:
</tt><br>
<tt> </tt><br>
<tt> --- </tt><br>
<tt> 11: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 9000 qdisc noqueue state UP
</tt><br>
<tt> link/ether 3c:fd:fe:08:a7:c0 brd ff:ff:ff:ff:ff:ff </tt><br>
<tt> inet 10.225.71.107/20 brd 10.225.79.255 scope global bond0 </tt><br>
<tt> valid_lft forever preferred_lft forever </tt><br>
<tt> inet6 fe80::3efd:feff:fe08:a7c0/64 scope link </tt><br>
<tt> valid_lft forever preferred_lft forever </tt><br>
<tt> --- </tt><br>
<tt> </tt><br>
<tt> which is a bond of p2p1 and p2p2. </tt><br>
<tt> </tt><br>
<tt> --- </tt><br>
<tt> 6: p2p1: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 9000 qdisc mq master bond0 state UP qlen 1000
</tt><br>
<tt> link/ether 3c:fd:fe:08:a7:c0 brd ff:ff:ff:ff:ff:ff </tt><br>
<tt> 7: p2p2: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 9000 qdisc mq master bond0 state UP qlen 1000
</tt><br>
<tt> link/ether 3c:fd:fe:08:a7:c0 brd ff:ff:ff:ff:ff:ff </tt><br>
<tt> --- </tt><br>
<tt> </tt><br>
<tt> A similar bond0 exists on sgate2. </tt><br>
<tt> </tt><br>
<tt> I crawled around in /usr/lpp/mmfs/lib/mmsysmon/CESNetworkService.py for a while trying to figure it out, but have been unsuccessful so far.</tt><br>
<tt> </tt><br>
<tt> </tt><br>
<br>
<tt>_______________________________________________</tt><br>
<tt>gpfsug-discuss mailing list</tt><br>
<tt>gpfsug-discuss at spectrumscale.org</tt><br>
</span><a href="http://gpfsug.org/mailman/listinfo/gpfsug-discuss"><tt><span style="font-size:10.0pt">http://gpfsug.org/mailman/listinfo/gpfsug-discuss</span></tt></a><span style="font-size:10.0pt;font-family:"Courier New""><br>
</span><br>
<br>
<br>
<br>
<o:p></o:p></p>
</div>
</body>
</html>