first good that the problem at least is solved, it would be great if you could open a PMR so this gets properly fixed, the daemon shouldn't segfault, but rather print a message that the device is too big.
on the caching , it only gets used when you run out of pagepool or when you run out of full file objects . so what benchmark, test did you run to push data into LROC ? sven On Thu, Dec 29, 2016 at 5:41 PM Matt Weil <[email protected]> wrote: > after restart. still doesn't seem to be in use. > > [root@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 <[email protected]> > 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 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 > > > > -- > Aaron Knister > NASA Center for Climate Simulation (Code 606.2) > Goddard Space Flight Center > (301) 286-2776 <%28301%29%20286-2776> > _______________________________________________ > gpfsug-discuss mailing list > gpfsug-discuss at spectrumscale.org > http://gpfsug.org/mailman/listinfo/gpfsug-discuss > > > > _______________________________________________ > gpfsug-discuss mailing list > gpfsug-discuss at > spectrumscale.orghttp://gpfsug.org/mailman/listinfo/gpfsug-discuss > > > > > _______________________________________________ > gpfsug-discuss mailing list > gpfsug-discuss at > spectrumscale.orghttp://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
