<html><head><META http-equiv="Content-Type" content="text/html;charset=utf-8"></head><body><div id="content" contenteditable="true" spellcheck="true" autocorrect="true" autocapitalize="true" style="font-family: Helvetica;"><font face="-apple-system, Helvetica"><span style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.301961); -webkit-text-size-adjust: auto; background-color: rgba(255, 255, 255, 0);"><i>Valdis wrote:</i></span></font><div><font face="-apple-system, Helvetica"><span style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.301961); -webkit-text-size-adjust: auto; background-color: rgba(255, 255, 255, 0);"><i>Keep in mind that if you have multiple NSD servers in the cluster, there<br>is *no* guarantee that the names for a device will be consistent across<br>the servers, or across reboots. And when multipath is involved, you may<br>have 4 or 8 or even more names for the same device....</i></span></font><br><br>Indeed the is whole greatness about NSDs (and in passing why Lustre can be much more tricky to safely manage.)</div><div>Once a lun is "labelled" as an NSD then that NSD name is all you need to care about as the /dev entries can now freely change on reboot or differ across nodes. Indeed if you connect an arbitrary node to an NSD disk via a SAN cable, gpfs will recognise it and use it as a shortcut to that lun.</div><div><br></div><div>Finally recall that in the NSD stanza file the /dev entry is only matched for on the first of the listed NSD servers; the other NSD servers will discover and learn which NSD this is, ignoring the /dev value in this stanza.</div><div><br>Daniel<br><br>IBM Spectrum Storage Software<br><a dir="ltr" href="tel:+44%207818%20522266" x-apple-data-detectors="true" x-apple-data-detectors-type="telephone" x-apple-data-detectors-result="0">+44 (0)7818 522266</a><br>Sent from my iPad using IBM Verse<br><br><br><hr>On 17 Dec 2016, 21:43:00, Valdis.Kletnieks@vt.edu wrote:<br><br>From: Valdis.Kletnieks@vt.edu<br>To: gpfsug-discuss@spectrumscale.org<br>Cc: <br>Date: 17 Dec 2016 21:43:00<br>Subject: Re: [gpfsug-discuss] translating /dev device into nsd name<br><br><div id="MaaS360PIMSDKOriginalMessageId">On Fri, 16 Dec 2016 23:24:34 -0500, Aaron Knister said:<br>> that I can then parse and map the nsd id to the nsd name. I hesitate<br>> calling ts* commands directly and I admit it's perhaps an irrational<br>> fear, but I associate the -D flag with "delete" in my head and am afraid<br>> that some day -D may be just that and *poof* there go my NSD descriptors.<br>Others have mentioned mmlsdnsd -m and -X<br>Keep in mind that if you have multiple NSD servers in the cluster, there<br>is *no* guarantee that the names for a device will be consistent across<br>the servers, or across reboots. And when multipath is involved, you may<br>have 4 or 8 or even more names for the same device....<br>_______________________________________________<br>gpfsug-discuss mailing list<br>gpfsug-discuss at spectrumscale.org<br>http://gpfsug.org/mailman/listinfo/gpfsug-discuss<br></div></div></div>Unless stated otherwise above:<BR>
IBM United Kingdom Limited - Registered in England and Wales with number 741598. <BR>
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU<BR>
<BR>
</body></html>