Indeed. It only matters when deploying NSDs. Post-deployment, all luns (NSDs) are labeled - and they are assembled by GPFS.
Keep in mind: If you are deploying multiple NSDs (with multiple servers) - you'll need to pick one server to work with... Use that server to label the luns (mmcrnsd)... In the nsd stanza file - the server you choose will need to be the first server in the "servers" list. Ken Hill Technical Sales Specialist | Software Defined Solution Sales IBM Systems Phone:1-540-207-7270 E-mail: [email protected] 2300 Dulles Station Blvd Herndon, VA 20171-6133 United States From: "Daniel Kidger" <[email protected]> To: "gpfsug main discussion list" <[email protected]> Cc: "gpfsug main discussion list" <[email protected]> Date: 12/19/2016 06:42 AM Subject: Re: [gpfsug-discuss] translating /dev device into nsd name Sent by: [email protected] Valdis wrote: Keep in mind that if you have multiple NSD servers in the cluster, there is *no* guarantee that the names for a device will be consistent across the servers, or across reboots. And when multipath is involved, you may have 4 or 8 or even more names for the same device.... Indeed the is whole greatness about NSDs (and in passing why Lustre can be much more tricky to safely manage.) 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. 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. Daniel IBM Spectrum Storage Software +44 (0)7818 522266 Sent from my iPad using IBM Verse On 17 Dec 2016, 21:43:00, [email protected] wrote: From: [email protected] To: [email protected] Cc: Date: 17 Dec 2016 21:43:00 Subject: Re: [gpfsug-discuss] translating /dev device into nsd name On Fri, 16 Dec 2016 23:24:34 -0500, Aaron Knister said: > that I can then parse and map the nsd id to the nsd name. I hesitate > calling ts* commands directly and I admit it's perhaps an irrational > fear, but I associate the -D flag with "delete" in my head and am afraid > that some day -D may be just that and *poof* there go my NSD descriptors. Others have mentioned mmlsdnsd -m and -X Keep in mind that if you have multiple NSD servers in the cluster, there is *no* guarantee that the names for a device will be consistent across the servers, or across reboots. And when multipath is involved, you may have 4 or 8 or even more names for the same device.... _______________________________________________ gpfsug-discuss mailing list gpfsug-discuss at spectrumscale.org http://gpfsug.org/mailman/listinfo/gpfsug-discuss Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU _______________________________________________ gpfsug-discuss mailing list gpfsug-discuss at spectrumscale.org http://gpfsug.org/mailman/listinfo/gpfsug-discuss
_______________________________________________ gpfsug-discuss mailing list gpfsug-discuss at spectrumscale.org http://gpfsug.org/mailman/listinfo/gpfsug-discuss
