On 12/29/16 10:02 AM, Aaron Knister wrote: > Interesting. Thanks Matt. I admit I'm somewhat grasping at straws here. > > That's a *really* long device path (and nested too), I wonder if > that's causing issues. was thinking of trying just /dev/sdxx > > What does a "tspreparedisk -S" show on that node? tspreparedisk:0::::0:0:: > > Also, what does your nsddevices script look like? I'm wondering if you > could have it give back "/dev/dm-XXX" paths instead of > "/dev/disk/by-id" paths if that would help things here. > if [[ $osName = Linux ]] > then > : # Add function to discover disks in the Linux environment. > for luns in `ls /dev/disk/by-id | grep nvme` > do > all_luns=disk/by-id/$luns > echo $all_luns dmm > done > > fi >
I will try that. > > -Aaron > > On 12/29/16 10:57 AM, Matt Weil wrote: >> >> >>> ro_cache_S29GNYAH200016 0A6403AA586531E1 >>> /dev/disk/by-id/nvme-Dell_Express_Flash_NVMe_SM1715_1.6TB_SFF_______S29GNYAH200016 >>> >>> dmm ces1.gsc.wustl.edu server node >> >> >> On 12/28/16 5:19 PM, Aaron Knister wrote: >>> mmlssnsd -X | grep 0A6403AA58641546 >> >> _______________________________________________ >> 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