[gpfsug-discuss] LROC

[Matt Weil]

after restart. still doesn't seem to be in use.

> [root at ces1 ~]# 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:35:32 2016
>
> Total objects stored 0 (0 MB) recalled 0 (0 MB)
>       objects failed to store 0 failed to recall 0 failed to inval 0
>       objects queried 0 (0 MB) not found 0 = 0.00 %
>       objects invalidated 0 (0 MB)


On 12/29/16 10:28 AM, Matt Weil wrote:
>
> 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/c161b040/attachment.htm>