[gpfsug-discuss] LROC

[Matt Weil]

wow that was it.

>  mmdiag --lroc
>
> === mmdiag: lroc ===
> LROC Device(s): '0A6403AA5865389E#/dev/nvme0n1;' status Running
> Cache inodes 1 dirs 1 data 1  Config: maxFile 1073741824 stubFile
> 1073741824
> Max capacity: 1526184 MB, currently in use: 0 MB
> Statistics from: Thu Dec 29 10:08:58 2016
It is not caching however.  I will restart gpfs to see if that makes it
start working.


On 12/29/16 10:18 AM, Matt Weil wrote:
>
>
>
> On 12/29/16 10:09 AM, Sven Oehme wrote:
>> i agree that is a very long name , given this is a nvme device it
>> should show up as /dev/nvmeXYZ
>> i suggest to report exactly that in nsddevices and retry.
>> i vaguely remember we have some fixed length device name limitation ,
>> but i don't remember what the length is, so this would be my first
>> guess too that the long name is causing trouble.
> I will try that.  I was attempting to not need to write a custom udev
> rule for those. Also to keep the names persistent.  Rhel 7 has a
> default rule that makes a sym link in /dev/disk/by-id.
> 0 lrwxrwxrwx 1 root root  13 Dec 29 10:08
> nvme-Dell_Express_Flash_NVMe_SM1715_1.6TB_SFF_______S29GNYAH200016 ->
> ../../nvme0n1
> 0 lrwxrwxrwx 1 root root  13 Dec 27 11:20
> nvme-Dell_Express_Flash_NVMe_SM1715_1.6TB_SFF_______S29GNYAH300161 ->
> ../../nvme1n1
>>
>>
>> On Thu, Dec 29, 2016 at 5:02 PM Aaron Knister
>> <aaron.s.knister at nasa.gov <mailto:aaron.s.knister at nasa.gov>> 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.
>>
>>     What does a "tspreparedisk -S" show on that node?
>>
>>     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.
>>
>>     -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 <http://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://spectrumscale.org>
>>     > http://gpfsug.org/mailman/listinfo/gpfsug-discuss
>>     >
>>
>>     --
>>     Aaron Knister
>>     NASA Center for Climate Simulation (Code 606.2)
>>     Goddard Space Flight Center
>>     (301) 286-2776 <tel:%28301%29%20286-2776>
>>     _______________________________________________
>>     gpfsug-discuss mailing list
>>     gpfsug-discuss at spectrumscale.org <http://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
>
>
>
> _______________________________________________
> gpfsug-discuss mailing list
> gpfsug-discuss at spectrumscale.org
> http://gpfsug.org/mailman/listinfo/gpfsug-discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://gpfsug.org/pipermail/gpfsug-discuss_gpfsug.org/attachments/20161229/13e84e36/attachment-0002.htm>