March 2016 - Neurosis - mailman3.cels.anl.gov

Re: [Neurosis] KDSA BD and xmem
by Brian R. Toonen 21 Mar '16

21 Mar '16

This issue has been resolved. The service is once again starting automatically at boot time. --brian On 2016-03-20 21:01, Brian R. Toonen wrote: > We've tried several things, rebooted a few times, and don't understand the reason for the KDSA service failing to load the driver at boot. However, starting the KDSA service manually after boot seems to result in the desired environment. So, for now, if you reboot neurosis, please run 'sudo /etc/init.d/kdsa start' after the machine has finished booting. Once this command is run, the kernel driver and kdsa_manage should operate as expected. We will continue investigating and let you know once the situation has been resolved. > > --brian > > On 2016-03-20 18:32, Brian R. Toonen wrote: >> I upgraded the KDSA kernel module on neurosis to match the version on cooley, but something's not right. For now, kdsa_manage is not functioning and thus connections can not be established through the block device and xmemfs. I'm leaving the system in its current state so that Kove can take a look. If you require access to your volume through the block device or xmemfs, let me know and I will reinstall the older driver. >> >> BTW, the KDSA C API is still functioning properly, assuming you know the connect string for your volume. The header and library files have moved to /soft/libraries/kove/api/current. I will provide more details on that in a separate email. >> >> --brian >>

1 0

Re: [Neurosis] KDSA BD and xmem
by Brian R. Toonen 20 Mar '16

20 Mar '16

We've tried several things, rebooted a few times, and don't understand the reason for the KDSA service failing to load the driver at boot. However, starting the KDSA service manually after boot seems to result in the desired environment. So, for now, if you reboot neurosis, please run 'sudo /etc/init.d/kdsa start' after the machine has finished booting. Once this command is run, the kernel driver and kdsa_manage should operate as expected. We will continue investigating and let you know once the situation has been resolved. --brian On 2016-03-20 18:32, Brian R. Toonen wrote: > I upgraded the KDSA kernel module on neurosis to match the version on cooley, but something's not right. For now, kdsa_manage is not functioning and thus connections can not be established through the block device and xmemfs. I'm leaving the system in its current state so that Kove can take a look. If you require access to your volume through the block device or xmemfs, let me know and I will reinstall the older driver. > > BTW, the KDSA C API is still functioning properly, assuming you know the connect string for your volume. The header and library files have moved to /soft/libraries/kove/api/current. I will provide more details on that in a separate email. > > --brian >

1 0

KDSA BD and xmem
by Brian R. Toonen 20 Mar '16

20 Mar '16

I upgraded the KDSA kernel module on neurosis to match the version on cooley, but something's not right. For now, kdsa_manage is not functioning and thus connections can not be established through the block device and xmemfs. I'm leaving the system in its current state so that Kove can take a look. If you require access to your volume through the block device or xmemfs, let me know and I will reinstall the older driver. BTW, the KDSA C API is still functioning properly, assuming you know the connect string for your volume. The header and library files have moved to /soft/libraries/kove/api/current. I will provide more details on that in a separate email. --brian

1 0

kove group has been changed to RAN
by Brian R. Toonen 09 Mar '16

09 Mar '16

In the interested of making neurosis more consist with cooley, the group formerly known as 'kove' is now called 'RAN'. The gid is still 511, so the change should be largely transparent. The exception is if the 'kove' group name is used in a config file, script, etc. Those instances need to be changed. I have already updated the following config files. /etc/security/limits.conf /etc/security/limits.conf /etc/udev/rules.d/90-rdma.rules --brian

1 0

JLSE XPD volumes
by Brian R. Toonen 04 Mar '16

04 Mar '16

Today, and possibly over the weekend, I will be prototyping a basic toolset for helping users acquire XPD space, obtain the appropriate connection strings for a volume set, connect volumes needed for a job to execute, etc. To do this, I will need to destroy existing volumes and create new ones, probably destroying all of them at one or more points. If you need the data in any of the existing volumes, please let me know ASAP. If you require one or more volumes in order to continue working, please let me know how many and what size, and I will create them in a way that my scripts consider them off limits. --brian

1 0