[gpfsug-discuss] LROC
Matt Weil
mweil at wustl.edu
Thu Dec 29 16:28:32 GMT 2016
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>
More information about the gpfsug-discuss
mailing list